FAST 14 On the Energy Overhead of Mobile Storage Systems 移动存储系统的能耗开销

本文探讨了移动存储系统的能耗问题,发现软件栈、加密及runtime是主要能耗来源。针对此,提出了使用原生API、硬件加速和选择性加密等策略来降低能耗。实验表明,顺序读取最省电,而加密和托管语言运行增加显著能耗。建议优化这些方面以提升移动设备的能效。
摘要由CSDN通过智能技术生成

On the Energy Overhead of Mobile Storage Systems

移动存储系统的能耗开销

文章链接

FAST 14

加州大学圣地亚哥分校 微软

用的是10年底发布的三星Samsung Galaxy nexus 以及12年中发布的surface平板

已经落后于时代了

1、总结

本文发现移动设备的存储硬件能耗不高,能耗主要在存储的软件栈上。
其中占主要部分的是数据加密以及runtime的开销。
对此提出了使用原生API、硬件加速、选择性加密3个降低移动设备能耗的方案

2、几个发现

实验设备用的Monsoon power monitor

本文的测试平台是windows RT(arm上的win平板,现在的surface用的intel)以及安卓机

2.1 软件存储栈开销大

存储设备能耗低,可以忽略不计,但整个存储栈(包括因为IO引起的DRAM、CPU能耗等)能耗就高了
在这里插入图片描述

详细数据如下

下图是windows RT上裸emmc 4.5设备的能耗开销(直接通过emmc上的设备能耗检测的)
在这里插入图片描述

概括起来就是大概1uJ/KB 左右

但是整个存储栈的能耗开销是设备的100倍以上
安卓的随机写甚至达到设备能耗的1000倍
在这里插入图片描述

有一点小的细节:

  • 顺序读非常省电

2.2 加密的开销

出于信息安全考虑,数据需要加密
比如说拔掉你的硬盘插别的电脑上读取 😟
windows有bitlocker,安卓也可以自己设置加密
在这里插入图片描述

加密相比不加密多出来的能耗开销如下
总之,大体上是原来的2-6倍
在这里插入图片描述

2.3 runtime的开销

托管型程序语言(微软的一个模糊定义):
需要相应的解释环境才可以运行,编译后不是直接生成机器码
比如C# Java Python是托管型
C C++ 就不是

出于安全性的考虑,要让设备上的应用被隔离,不能让他们访问一些敏感资源,比如密码、地理位置等,所以他们的编程也是采用托管代码隔离于操作系统内核

安卓架构如下,可以看到最底层是C编译的Linux内核,其上的runtime为ART
上层应用程序需要借助Java提供的API,借助ART才能运行
在这里插入图片描述

Windows RT平板三星安卓手机
托管语言C#Java
runtime.NetJVM

在这里插入图片描述

用了原生的C语言应用程序和需要托管语言的程序对比

  • runtime的开销在安卓上比较大,顺序读写多20%左右能耗,随机读多1倍能耗

增大IO大小,安卓的多出的能耗会减少,这里随机读能耗增加这么多,主要还是因为过量预取,见[[监测App文件]]

  • 在win平板上只多15%左右的能耗

3、如何减少移动设备存储的能耗

  1. 不要所有数据加密,选择性地加密
    减少加密开销

  2. 尽量用原生IO 的API
    减少runtime开销

  3. 使用硬件加速

本文还建立了一个能耗模型EMOS

参考资料

  1. bitLocker
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值