HDC2021技术分论坛:HarmonyOS内核技术大揭秘!
作者:jikecheng,miaoxie,HarmonyOS内核技术专家
HarmonyOS整体框架分为四个层级,如图1所示。从上到下,依次为:第一层是应用层,主要涵盖系统应用、Launcher、设置,以及三方应用。第二层是框架层,提供基础UI框架、用户程序框架以及能力模块框架。第三层是系统服务层,让HarmonyOS具有分布式流转负载的能力。大家看到的高速多设备协同能力就是由该层级提供。
而承载整个操作系统,同时发挥芯片算力的基石就沉淀在第四层——内核层。宏观来说,内核的主要工作包含芯片资源管理、软件任务调度,以及衔接用户空间与系统调用能力。
图1 HarmonyOS整体框架
本期,我们要重点给大家讲一讲HarmonyOS的内核层。
一、HarmonyOS内核构成
为了支撑HarmonyOS在多设备、多场景下的性能表现,内核主要由三部分组成,如下图所示:
图2 内核的组成
- HarmonyOS内核组件:具有智慧化资源管理能力的内核组件,包括CPU/GPU资源管理,内存管理,IO调度管理以及高效的文件系统等。
- 标准的Linux内核:兼容了LTS Linux主线版本,做好外围生态的对接。
- 硬件平台BSP:面向各种不同芯片与硬件平台(包含1+8+N的多种设备)的BSP(board support package,板级支撑包)基础能力。
本期要为大家介绍的就是HarmonyOS内核组件的三项核心技术:高能效CPU资源调度、Hyperhold内存管理引擎和高效的文件系统。下面为大家一一揭晓~
二、高能效CPU资源调度
业界多数的操作系统都是基于标准的Linux内核开发的。传统的Linux内核,早期用于服务器和PC设备,与我们现在用于手机、平板等的交互式内核相比,它们的设计理念和资源管理方式有所不同。以CPU资源为例,传统的Linux内核存在以下典型问题:
1. 同优先级的业务过多,每次调度都不一定选择到关键进程。
传统的Linux内核偏向于在多用户的场景下公平地分配资源。比较明显的特征是,多个用户并发访问,并发使用公共资源。由于同优先级的业务比较多,每次任务调度不一定能够选择到关键进程。举个例子,当设备后台存在多个应用或者服务任务时,系统中和用户交互最敏感的渲染任务没法即时得到调度资源,导致设备会高概率出现使用不流畅或者点击无响应的现象,也就是咱们平时常说的随机卡顿。
2. 选择最优能效的CPU资源时间过长,CPU资源选择过度。
传统的Linux内核选择算力的流程,是一个慢速爬坡的过程。任务调度必须经过选择CPU核簇、负载均衡、选择频点等一系列流程。其漫长的过程,极易导致任务调度错过调度窗口,出现算力供给不足的现象。
为了解决以上问题,HarmonyOS内核提供了全栈式的调度框架,如下图所示:
图3 HarmonyOS调度管理框架
HarmonyOS调度管理框架有以下特点:
● 任务按优先级调度
对现有系统任务进行严格级别划分,在线标记与用户的操作体验直接相关的关键进程和关联任务,优先调度关键任务。
● 依据CPU负载情况选择最优任务分配
我们会动态检测不同CPU的负载,保证当前CPU有足够的算力提供。
● 选择最优频点实现高能效
我们提供了频点与性能、功耗之间的帕累托最优模型。每次任务,我们都能够快速选择系统最优的频点组合方式,实现最优能效。
经过试验,HarmonyOS的全栈式调度框架可以帮助用户获得在多场景(尤其是游戏场景)下持续且稳定的高帧率体验。
三、Hyperhold内存管理引擎
对于内存管理,由于开源生态的不限制,导致应用开发的内存使用野蛮生长。设备长时间使用后,可回收内存越来越低。产生这个问题的原因有两个:
1. 传统内存数据冷热管理,无法感知业务特性
尽管Linux内核提供了很多的内存回收机制,然而每种内存回收都会有相应的系统代价。比如,回收文件页面后,如果系统需要二次加载这部分数据,需要从底层器件Flash里面把数据读回来,这会引起Flash随机IO读的现象。对IO操作来说,Flash器件速度和当前读取任务是随机读还是顺序读有着很强的相关性,随机读容易导致系统随机卡顿。再比如,回收匿名页面后,如果系统需要二次加载这部分数据,会触发ZRAM解压,消耗CPU。
另外,由于应用的内存负载越来越重,当系统冷热数据识别不恰当,会导致系统的CPU负载长期处于高负载状态,最终影响前台应用的基础性能。
2. 传统共享式内存分配,无法感知数据重要性
从内存分配角度看,现在的操作系统基本采用统一接口的分配方式,使得手机里面多个进程或多个业务会共用一块内存区域。数据回收时,会频繁出现数据搬移,以及内存震荡的现象。这个现象会加重内核管理内存的开销。
为了解决传统Linux内核的内存问题,HarmonyOS提供了Hyperhold内存管理引擎。Hyperhold内存管理引擎打通了上层系统到内核的调用栈,让内核完整感知到应用的整个生命周期,并结合应用生命周期以及周期内的数据访问特征,对每一块内存数据做合理的内存管理。同时,为了降低内核管理内存的开销,我们提出了自研的压缩体系,包括多线程压缩、自研的压缩算法。为了进一步扩大可用空间,我们在Flash器件上开出了一块可交换区,结合自研的聚合换出和内存标记技术,充分利用Flash器件的性能。
图4 Hyperhold内存管理引擎
经过试验, Hyperhold内存管理引擎可以让应用在后台的驻留能力提升50%以上,用户可以明显感知到后台应用的保活率有大幅提升。
四、高效的文件系统
存储处于整个缓存体系下的最慢路径,容易成为系统性能瓶颈。不仅如此,由于存储器件碎片化的问题,存储还容易出现越用越慢的难题。其次,随着系统的发展,系统占用存储越来越多。而在多设备流转的场景下,分布式文件系统的高效转存能力显得尤为重要。
为应对上述问题,HarmonyOS提供了高效的自研文件系统体系。从第一代的eF2FS到最新的HMDFS,文件系统逐步解决了碎片化问题、容量问题与多设备流转问题。
图5 HarmonyOS文件系统
下面我们从第一代的eF2FS到最新的HMDFS,依次介绍HarmonyOS文件系统的技术特点。
1. 第1代数据盘eF2FS:智能感知空间管理,改善越用越慢
面对存储越用越慢的业界难题,我们通过数据类型感知的多流算法和空间感知的分配算法,减少碎片产生。同时,通过高效、业务感知的两层智能垃圾空间回收,实现智能感知空间管理。
下面我们通过一个动图,更好地了解HarmonyOS的空间管理机制。
2. 系统盘EROFS:变长压缩,支持压缩与性能双赢
针对系统占用存储越来越多的问题,业界其他操作系统也采取过改进措施,比如squashfs采用“定长输入,变长输出”的压缩策略,但会存在读放大的问题。而我们的EROFS(Extendable Read-Only File System,超级文件系统)采用“变长输入,定长输出”的压缩策略,尽可能地将不等长的文件块压缩成一个等长的存储块进行存储。这样,我们访问任何文件块,只需读取一个存储块,减少了无效读取。除此之外,我们在解压性能和IO流程上也做了优化。
图6 系统盘EROFS的变长压缩
通过以上关键技术,系统盘EROFS的性能得到大幅提升:
- 随机读性能平均提升20%。
- 系统初始空间相比Ext4节省2GB,相当于用户可以多存1000张照片或500首歌曲。
- 升级包大小下降约5%-10%,升级时间缩短约20%。
3. 跨设备HMDFS:“批流”结合的分布式文件系统
HarmonyOS同一套系统能力、适配多种终端形态的分布式理念,就要求我们有一套数据流转的底座——分布式文件系统HMDFS。
图7 HMDFS
应对多设备流转,HMDFS提供了多种文件系统能力,包括:
- 文件类型聚合
- 高效的缓存管理
- 批处理接口
- 分布式的权限管控
- 高效传输
- 数据一致性管理
通过上述一系列技术的研发与集成,最终实现了现有的跨设备高效文件系统,为用户提供流畅的分布式体验。
五、未来演进方向
上面就是我们本期要介绍的HarmonyOS内核核心技术内容了。未来还有很多方向值得我们继续探索,下图列出了HarmonyOS内核的未来演进方向。
图8 未来演进方向
相信经过我们不断的探索,我们能打造出更好的内核,为大家提供更流畅、体验更好的HarmonyOS!