[文章]HDC2021技术分论坛:HarmonyOS内核技术大揭秘!

阅读量0
0
1
作者: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!




回帖

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容图片侵权或者其他问题,请联系本站作侵删。 侵权投诉
链接复制成功,分享给好友