linux cpufreq framework(5)_ARM big Little driver

1. 前言

也许大家会觉得奇怪：为什么Linux kernel把对ARM big·Lttile的支持放到了cpufreq的框架中？

众所周知，ARM的big·Little架构，也称作HMP（具体可参考“Linux CPU core的电源管理(2)_cpu topology”中相关的介绍），通过在一个chip中封装两种不同类型的ARM core的方式，达到性能和功耗的平衡。这两类ARM Core，以cluster为单位，一类为高性能Core（即big core），一类为低性能Core（即Little core），通过它们的组合，可以满足不同应用场景下的性能和功耗要求，例如：非交互式的后台任务、或者流式多媒体的解码，可以使用低功耗的Little core处理；突发性的屏幕刷新，可以使用高性能的big core处理。

那么问题来了，Linux kernel怎么支持这种框架呢？

注1：本文很多理论性的表述，或多或少的理解并翻译自：“http://lwn.net/Articles/481055/”，感兴趣的读者可以自行阅读。

注2：本文基于linux-3.18-rc4内核，其它版本内核可能会稍有不同。

2. Linux kernel支持ARM big·Lttile框架的思路

以一个包含两个cluster，cluster0有4个A15 core，cluster1有4个A7 core为例，我们会很自然的想到，可以把这8个core统统开放给kernel，让kernel的调度器（scheduler）根据系统的实际情况，决定哪些任务应该在哪些core上执行。但这存在一个问题：

当前linux kernel的scheduler，都是针对SMP系统设计的，而SMP系统中所有CPU core的性能和功耗都是相同的。

换句话说：kernel中还没有适用于big·Little架构的scheduler。怎么办？等待这样的一个scheduler出现？芯片厂商当然等不及，市场上已经出现了很多这种架构的芯片。为了应对这种软件滞后于硬件的现象（当前这种现象比比皆是，可能是硬件的成本比软件的人力成本低吧），ARM公司提出了这样一种软件解决方案（这只是ARM提出的解决方案的一种，后续我们介绍PSCI时，还会接触其它方案，这里就不再提及）：

使用一个hypervisor（可以参考“ARMv8-a架构简介”中有关hypervisor的介绍），利用虚拟化扩展，将8个A15+A7 core虚拟为4个A15 core，这样OS kernel就可以以SMP的方式，和这4个虚拟的core交互。当OS需要的时候，可以通过一个hypervisor指令，让某一个虚拟的core在A15和A7两种模式下切换，所有的切换动作，包括IRQ、timer等的迁移，都由hypervisor负责，对OS是透明的。

上面的方法有两个缺点：

1）这8个core不能任意的组合使用

2）必须存在hypervisor，会增加系统的复杂度

linux 借鉴了这个思路，将ARM hypervisor相关的实现逻辑，移植到kernel中，借助cpufreq framework，来实现上面的功能。之所以将hypervisor移植到kernel，是为了降低对ARM hypervisor code的耦合要求（解决上面的缺点2，当然，缺点1暂时无法解决）。而之所以使用cpufreq的框架，其中的思考如下：

1）抛开在big core和Little core之间切换的代价不谈，对scheduler来说，big core和Little core的区别仅仅在core的性能和功耗上，这恰恰和cpufreq framework的关注点一致：频率降低，性能降低，功耗降低；频率增大，性能增强，功耗增大。因此，可以将big、Little的切换，嵌入到CPU的频率调整中，低范围的频率段，对应Little core，高范围的频率段，对应big core。

2）对kernel scheduler而言，上面的8个core只有4个可见，这4个可见的core具有较宽的频率范围，并在big·Little switcher使能的情况下，根据频率需求的情况，自动在big和Little之间切换。

3）因此，使用cpufreq框架，巧妙的将不对称HMP架构，转化为了SMP架构，这样，kernel现有的scheduler就派上用场了。