1. 前言
由“
Linux CPU core的电源管理(1)_概述”的描述可知，kernel cpu control位于“.kernelcpu.c”中，是一个承上启下的模块，负责屏蔽arch-dependent的实现细节，向上层软件提供控制CPU
core的统一API（主要包括cpu_up/cpu_down等接口的实现）。本文将基于这些API，从上到下，分析CPU core从启动到关闭的整个过程（主要是CPU hotplug），进一步理解系统运行过程中CPU core电源管理相关的行为。
注1：其实这一部分已经不属于电源管理的范畴了，而是系统级的软件行为（boot、调度、电源管理等等），之所以放到这里讲述，主要原因是，这些复杂行为的背后，目的只有一个----节电。因此，本文只会focus在CPU core power状态切换的过程上，涉及到得其它知识，如进程调度，只会一笔带过。
2. possible/present/active/online cpus
前面文章提到过，kernel使用4个bitmap，来保存分别处于4种状态的CPU core：possible、present、active和online。这四个状态的意义到底是什么？下面我们根据相关的代码逻辑，来解答这个问题。
开始之前，先看一下kernel中对他们的注释：
1:
/* include/linux/cpumask.h */
2:
3:
4:
/*
5: * The following particular system cpumasks and operations manage
6: * possible, present, active and online cpus.
7: *
8: * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
9: * cpu_present_mask - has bit 'cpu' set iff cpu is populated
10: * cpu_online_mask - has bit 'cpu' set iff cpu available to scheduler
11: * cpu_active_mask - has bit 'cpu' set iff cpu available to migration
12: *
13: * If !CONFIG_HOTPLUG_CPU, present == possible, and active == online.
14: *
15: * The cpu_possible_mask is fixed at boot time, as the set of CPU id's
16: * that it is possible might ever be plugged in at anytime during the
17: * life of that system boot. The cpu_present_mask is dynamic(*),
18: * representing which CPUs are currently plugged in. And
19: * cpu_online_mask is the dynamic subset of cpu_present_mask,
20: * indicating those CPUs available for scheduling.
21: *
22: * If HOTPLUG is enabled, then cpu_possible_mask is forced to have
23: * all NR_CPUS bits set, otherwise it is just the set of CPUs that
24: * ACPI reports present at boot.
25: *
26: * If HOTPLUG is enabled, then cpu_present_mask varies dynamically,
27: * depending on what ACPI reports as currently plugged in, otherwise
28: * cpu_present_mask is just a copy of cpu_possible_mask.
29: */
30:
大意是这样的：
possible状态的CPU意味着是“populatable（觉得这个单词还没有possible易懂）”的，可理解为存在这个CPU资源，但还没有纳入Kernel的管理范围；
present状态的CPU，是已经“populated”的CPU，可理解为已经被kernel接管；
online状态的CPU，表示可以被调度器使用；
active状态的CPU，表示可以被migrate（什么意思？）；
如果系统没有使能CPU Hotplug功能，则present等于possible，active等于online。
还真不是很容易理解，不急，我们一个一个分析。
2.1 possible CPU
possible的CPUs，代表了系统中可被使用的所有的CPU，在boot阶段确定之后，就不会再修改。以ARM64为例，其初始化的过程如下。
1）系统上电后，boot CPU启动，执行start_kernel（init/main.c），并分别调用boot_cpu_init和setup_arch两个接口，进行possible CPU相关的初始化。
2）boot_cpu_init负责将当前的boot CPU放到possible CPU的bitmap中，同理，boot CPU也是present、oneline、active CPU（因此，后续的描述，都是针对非boot CPU的）。如下：
1:
/* init/main.c */
2:
3:
static void __init boot_cpu_init(
void)
4: {
5:
int cpu = smp_processor_id();
6:
/* Mark the boot cpu "present", "online" etc for SMP and UP case */
7: set_cpu_online(cpu, true);
8: set_cpu_active(cpu, true);
9: set_cpu_present(cpu, true);
10: set_cpu_possible(cpu, true);
11: }
smp_processor_id用于获取当前的CPU id；
set_cpu_xxx接口，可以将指定的CPU设置为（或者清除）指定的状态。
3）setup_arch负责根据MPIDR寄存器，以及DTS配置，解析并设置其它的possible CPU，如下：
1:
/* arch/arm64/kernel/setup.c */
2:
3:
void __init setup_arch(
char **cmdline_p)
4: {
5: ...
6: cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
7: cpu_read_bootcpu_ops();
8: #ifdef CONFIG_SMP
9: smp_init_cpus();
10: smp_build_mpidr_hash();
11: #endif
12: ...
13: }
14:
3a）cpu_logical_map数组
kernel使用一个整形数组（cpu_logical_map，定义如下），保存物理CPU（由ID标示）和逻辑CPU（数组的index）之间的映射，该数组的长度由NR_CPUS决定。
1:
/* arch/arm64/include/asm/smp_plat.h */
2:
3:
/*
4: * Logical CPU mapping.
5: */
6:
extern u64 __cpu_logical_map[NR_CPUS];
7: #define cpu_logical_map(cpu) __cpu_logical_map[cpu]
上面setup_arch代码的第六行，通过read_cpuid_mpidr接口，读取当前CPU（boot CPU）的ID（物理ID），并保存在map表的第一个位置。
3b）smp_init_cpus
如果使能了SMP，则调用smp_init_cpus接口，完成如下事情：
从DTS中解析其它CPU的HW ID（通过‘reg’关键字，如下），并保存在cpu_logical_map数组中；
对所有cpu_logical_map数组中的CPU，执行set_cpu_possible操作，将它们设置为possible状态。
1: {
2: ...
3: cpus {
4: #address-cells = <2>;
5: #size-cells = <0>;
6:
7: cpu@0 {
8: device_type = "
cpu";
9: compatible = "
arm,cortex-a53", "
arm,armv8";
10: reg = <0x0 0x0>;
11: enable-method = "
psci";
12: cpu-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
13: };
14:
15: cpu@1 {
16: device_type = "
cpu";
17: compatible = "
arm,cortex-a53", "
arm,armv8";
18: reg = <0x0 0x1>;
19: enable-method = "
psci";
20: cpu-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
21: };
22: ...
23: };
24: ...
25: }
26:
CPU DTS文件示例。
4）总结
对ARM64来说，possible的CPU，就是在DTS中指定了的，物理存在的CPU core。
2.2 present CPU
还是以ARM64为例，“start_kernel—>setup_arch”成功执行之后，继续执行“start_kernel—>rest_init—>kernel_init（pid 1，init task）—>kernel_init_freeable”，在kernel_init_freeable中会调用arch-dependent的接口：smp_prepare_cpus，该接口主要的主要功能有两个：
1）构建系统中CPU的拓扑结构，具体可参考“
Linux CPU core的电源管理(2)_cpu topology”。
2）拓扑结构构建完成后，根据CPU的拓扑，初始化系统的present CPU mask，代码如下：
1:
void __init smp_prepare_cpus(
unsigned int max_cpus)
2: {
3: ...
4:
/* Don't bother if we're effectively UP */
5:
if (max_cpus <= 1)
6:
return;
7:
8:
/*
9: * Initialise the present map (which describes the set of CPUs
10: * actually populated at the present time) and release the
11: * secondaries from the bootloader.
12: *
13: * Make sure we online at most (max_cpus - 1) additional CPUs.
14: */
15: max_cpus--;
16: for_each_possible_cpu(cpu) {
17:
if (max_cpus == 0)
18:
break;
19:
20:
if (cpu == smp_processor_id())
21:
continue;
22:
23:
if (!cpu_ops[cpu])
24:
continue;
25:
26: err = cpu_ops[cpu]->cpu_prepare(cpu);
27:
if (err)
28:
continue;
29:
30: set_cpu_present(cpu, true);
31: max_cpus--;
32: }
33: }
4~6行：当然，如果CPU个数不大于1，则不是SMP系统，就没有后续的概念，直接返回。
16~32行，轮询所有的possible CPU，如果某个CPU core满足一些条件，则调用set_cpu_present，将其设置为present CPU，满足的条件包括：具备相应的cpu_ops指针（有关cpu ops请参考“Linux CPU core的电源管理(3)_cpu
ops”）；cpu ops的.cpu_prepare回调成功执行。
由“
Linux CPU core的电源管理(3)_cpu ops”中有关CPU ops的解释可知，.cpu_prepare回调主要用于检查某个CPU是否具备执行的条件。如果.cpu_prepare执行成功，则说明该CPU是可以启动的。因此，present
CPU的意义是：
该CPU已经被kernel识别到，并且具备执行代码的条件，后续可以在需要的时候（如hotpulg的时候），启动该CPU。
2.3 online CPU
由前面present CPU可知，如果某个CPU是present的，则说明该CPU具备boot的条件，但是否已经boot还是未知数。
由“
Linux CPU core的电源管理(3)_cpu ops”的介绍可知，所谓的CPU boot，就是让CPU执行（取指译码/执行）代码（这里为linux kernel）。而CPU是否boot，则反映到online mask上，已经boot的CPU，会在secondary_start_kernel中，调用set_cpu_online接口，将其设置为online状态。反之，会在__cpu_disable中将其从online
mask中清除。
有关CPU boot的流程，请参考下面的介绍。
2.4 active CPU
在单核时代，调度器（scheduler）的职责很单纯：主要负责管理、调教一帮调皮捣蛋的task，尽量以“公平公正”的原则，为它们分配有限的CPU资源。
但在SMP系统中，特别是支持CPU hotplug的系统中，调度器需要多操一份心，即：
CPU资源可以在任何时候增加或者删除。增加的时候，需要将新增的资源分配给等待的task。删除的时候，需要将那些运行在这些CPU上的task，转移到其它尚存的CPU上（这个过程称作migration）。
要达到上面的目的，调度器需要监视CPU hotplug有关的每一个风吹草动。由于调度器和
CPU控制两个独立的模块，kernel通过notifier机制（“
Linux
CPU core的电源管理(1)_概述”中有提及，但没有过多介绍）实现这一功能。
简言之，每当系统的CPU资源有任何变动，
kernel CPU control模块就会通知调度器，调度器根据相应的event（CPU_DOWN_FAILED、CPU_DOWN_PREPARE等），调用set_cpu_active接口，将某个CPU添加到active
mask或者移出active mask。这就是active CPU的意义：
从调度器的角度，CPU的状态，即是否对调度器可见，或者说，调度器是否可以把task分配到这个CPU上运行。
注2：由此可知，active状态，只是为了方便调度器操作，抽象出的状态，和CPU电源管理之间没有耦合，后面就不在涉及这部分内容。
3. CPU的控制流程
CPU的控制流程，可以总结为up和down两种行为（和“.kernelcpu.c”中的cpu_up、cpu_down两个接口对应），up指CPU的启动过程，down指相反地过程。
根据CPU的发展过程，up和down的行为又可以分为三类：单核CPU的up/down；多核CPU的up/down；hotplugable CPU的up/down。下面让我们对这几种情况做一下简单的介绍。
3.1 单核CPU的控制流程
单核时代，只有一个CPU core，因此CPU的up/down，就是软件的整个生命周期（也就无所谓up/down了），如下：
1）系统上电，CPU从ROM代码执行，经bootloader（非必须），将控制权交给linux kernel。这就是cpu up的过程。
2）系统运行（一大堆省略号）。
3）由linux kernel及其进程调度算法所决定，不允许系统在没有CPU资源的情况下运行（这也是boot CPU的由来），所以系统的整个运行过程中，CPU都是up状态。
4）系统关闭，cpu down。
3.2 多核CPU的控制流程
linux kernel对待SMP系统的基本策略是：指定一个boot CPU，完成系统的初始化，然后再启动其它CPU。过程如下：
1）boot CPU启动，其up/down的控制流程和生命周期，和单核CPU一样。
2）boot CPU启动的过程中，调用cpu_up接口，启动其它CPU（称作secondary CPUs），使它们变成online状态（具体可参考“Linux CPU core的电源管理(3)_cpu ops”）。这就是secondary
CPUs的up过程。
3）由于CPU不支持hotplug功能，因此所有CPU只能up，不能down。直到系统关闭，才是cpu down。
3.3 CPU hotplug的控制流程
对于支持CPU hotplug功能的平台来说，可以在系统启动后的任意时刻，关闭任意一个secondary CPU（对ARM平台来说，CPU0或者说boot CPU，是不可以被关闭的），并在需要的时候，再次打开它。因此，相应的CPU控制流程如下：
1）boot CPU启动，其up/down的控制流程和生命周期，和单核CPU一样。
2）boot CPU启动的过程中，调用cpu_up接口，启动secondary CPU，使它们变成online状态，这是secondary CPUs的up过程的一种。
3）在系统负荷较低、或者不需要使用的时候，调用cpu_down接口，关闭不需要使用的secondary CPU，这是secondary CPUs的down过程。
4）在需要的时候，再次调用cpu_up接口，启动处于down状态的CPU，这是secondary CPUs的up过程的另一种。
有关CPU hotplug的具体说明，可参考后面描述。
4. CPU hotplug
4.1 CPU hotplug的时机
在kernel/cpu.c中，cpu_up接口，只会在使能了CONFIG_SMP配置项（意味着是SMP系统）后才会提供。而cpu_down接口，则只会在使能了CONFIG_HOTPLUG_CPU配置项（意味着支持CPU hotplug）后才会提供。
在当前kernel实现中，只支持通过sysfs的形式，关闭或打开CPU（当然，如果需要可以自定义一些方法，实现动态开关核的功能，本文就不在描述了），例如：
echo 0 > /sys/devices/system/cpu/cpuX/online # 关闭CPU
echo 1 > /sys/devices/system/cpu/cpuX/online # 打开CPU
另外，CPU hotplug还受“maxcpus”命令行参数影响：
系统启动的时候，可以通过命令行参数“maxcpus”，告知kernel本次启动所使用的CPU个数，该个数可以小于等于possible CPU的个数。系统初始化时，只会把“maxcpus”所指定个数的CPU置为present状态，具体可参考上面2.2小节所描述的smp_prepare_cpus的代码实现。
因此，CPU hotplug只能管理“maxcpus”所指定个数的CPU，具体可参考后面_cpu_up的流程分析。
注3：蜗蜗对这部分的理解，和“Documentationcpu-hotplug.txt”中的描述有出入，文档是这样描述的：
maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
maxcpus=2 will only boot 2. You can choose to bring the
other cpus later online, read FAQ's for more info.
它说其它CPU可以在后边被online，但从代码逻辑来说，没有机会online啊！先存疑吧！！
4.2 CPU hotplug的过程分析
CPU online的软件流程如下：
echo 0 > /sys/devices/system/cpu/cpuX/online
online_store(drivers/base/core.c)
device_online(drivers/base/core.c)
cpu_subsys_online(drivers/base/cpu.c)
cpu_up(kernel/cpu.c)
_cpu_up(kernel/cpu.c)
CPU offline的流程和online类似，不再详细介绍。这两个操作，最终是由cpu_up/cpu_down（也即_cpu_up/_cpu_down）两个接口实现的，下面我们重点分析这两个接口。
注4：内核中经常有这样的函数，xxx、_xxx或者__xxx，区别是一个或者两个下划线，其中的含义是：
xxx接口，通常需要由某个锁保护，一般提供给其它模块调用。它会直接调用_xxx接口；
_xxx接口，则不需要保护，一般由模块内部在确保安全的情况下调用。有时，外部模块确信可行（不需要保护），也可能会直接调用；
__xxx接口，一般提供给arch-dependent的软件层实现，比如这里的arch/arm64/kernel/xxx.c。
理解这些含义后，会加快我们阅读代码的速度，另外，如果直接写代码，也尽量遵守这样的原则，以便使自己的代码更规范、更通用。
4.3 cpu_up流程分析
cpu_up的基本流程如下所示：
其要点包括：
1）up前后，发送PREPARE、ONLINE、STARTING等notify，以便让关心者作出相应的动作，例如调度器、RCU、workqueue等模块，都需要关注CPU的hotplug动作，以便进行任务的重新分配等操作。
2）执行Arch-specific相关的boot操作，将CPU boot起来，最终通过secondary_start_kernel接口，停留在per-CPU的idle线程上。
下面我们结合代码，对上述过程做一个简单的分析。
4.3.1 per-CPU的idle线程
我们在“
linux cpuidle framework”的系列文章中，已经分析过linux cpuidle有关的工作原理，但却没有提及cpuidle的源头，这里我们补充回来。
首先，boot CPU在执行初始化动作的时候，会通过“smp_init—>idle_threads_init—>idle_init”的调用，为每个CPU创建一个idle线程，如下：
1:
/* kernel/smpboot.c */
2:
static inline
void idle_init(
unsigned int cpu)
3: {
4:
struct task_struct *tsk = per_cpu(idle_threads, cpu);
5:
6:
if (!tsk) {
7: tsk = fork_idle(cpu);
8:
if (IS_ERR(tsk))
9: pr_err("
SMP: fork_idle() failed for CPU %u
", cpu);
10:
else
11: per_cpu(idle_threads, cpu) = tsk;
12: }
13: }
该接口的本质是，为每个CPU fork一个idle thread（由struct task_struct结构表示），并保存在一个per-CPU的全局变量（idle_threads）中。
此时，idle thread只是一个task结构，并没有执行。那它最终怎么执行的呢？我们继续往后面看。
4.3.2 arch-specific CPU boot
_cpu_up接口会在完成一些准备动作之后，调用平台相关的__cpu_up接口，由平台代码完成具体的up操作，如下：
1:
static int _cpu_up(
unsigned int cpu,
int tasks_frozen)
2: {
3:
int ret, nr_calls = 0;
4:
void *hcpu = (
void *)(
long)cpu;
5:
unsigned long mod = tasks_frozen ? CPU_TASKS_FROZEN : 0;
6:
struct task_struct *idle;
7:
8: cpu_hotplug_begin();
9:
10:
if (cpu_online(cpu) || !cpu_present(cpu)) {
11: ret = -EINVAL;
12:
goto out;
13: }
14:
15: idle = idle_thread_get(cpu);
16:
if (IS_ERR(idle)) {
17: ret = PTR_ERR(idle);
18:
goto out;
19: }
20:
21: ret = smpboot_create_threads(cpu);
22:
if (ret)
23:
goto out;
24:
25: ret = __cpu_notify(CPU_UP_PREPARE | mod, hcpu, -1, &nr_calls);
26:
if (ret) {
27: nr_calls--;
28: pr_warn("
%s: attempt to bring up CPU %u failed
",
29: __func__, cpu);
30:
goto out_notify;
31: }
32:
33:
/* Arch-specific enabling code. */
34: ret = __cpu_up(cpu, idle);
35:
if (ret != 0)
36:
goto out_notify;
37: BUG_ON(!cpu_online(cpu));
38:
39:
/* Wake the per cpu threads */
40: smpboot_unpark_threads(cpu);
41:
42:
/* Now call notifier in preparation. */
43: cpu_notify(CPU_ONLINE | mod, hcpu);
44:
45: out_notify:
46:
if (ret != 0)
47: __cpu_notify(CPU_UP_CANCELED | mod, hcpu, nr_calls, NULL);
48: out:
49: cpu_hotplug_done();
50:
51:
return ret;
52: }
准备动作包括：
1）获取idle thread的task指针，该指针最终会以参数的形式传递给arch-specific代码。
2）创建一个用于管理CPU hotplug动作的线程（smpboot_create_threads），该线程的具体意义，后面会再说明。
3）发送CPU_UP_PREPARE notify。
以ARM64为例，__cpu_up的内部实现如下：
1:
/* arch/arm64/kernel/smp.c */
2:
int __cpu_up(
unsigned int cpu,
struct task_struct *idle)
3: {
4:
int ret;
5:
6:
/*
7: * We need to tell the secondary core where to find its stack and the
8: * page tables.
9: */
10: secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
11: __flush_dcache_area(&secondary_data,
sizeof(secondary_data));
12:
13:
/*
14: * Now bring the CPU into our world.
15: */
16: ret = boot_secondary(cpu, idle);
17:
if (ret == 0) {
18:
/*
19: * CPU was successfully started, wait for it to come online or
20: * time out.
21: */
22: wait_for_completion_timeout(&cpu_running,
23: msecs_to_jiffies(1000));
24:
25:
if (!cpu_online(cpu)) {
26: pr_crit("
CPU%u: failed to come online
", cpu);
27: ret = -EIO;
28: }
29: }
else {
30: pr_err("
CPU%u: failed to boot: %d
", cpu, ret);
31: }
32:
33: secondary_data.stack = NULL;
34:
35:
return ret;
36: }
该接口以idle thread的task指针为参数，完成如下动作：
1）将idle线程的堆栈，保存在一个名称为secondary_data的全局变量中（这地方很重要，后面再介绍其中的奥妙）。
2）执行boot_secondary接口，boot CPU，具体的流程，可参考“Linux CPU core的电源管理(3)_cpu ops”中的描述。
3）boot_secondary返回后，等待对应的CPU切换为online状态。
4.3.3 secondary_startup
“
Linux CPU core的电源管理(3)_cpu ops” 4.1小节，分析了使用SPIN TABLE cpu ops的情况下，boot_secondary到secondary_startup的流程（其它cpu ops类似），本文继续secondary_startup的分析。
该接口位于arch/arm64/kernel/head.S中，负责secondary CPU启动后的后期操作，如下：
1: ENTRY(secondary_startup)
2:
/*
3: * Common entry point for secondary CPUs.
4: */
5: mrs x22, midr_el1
// x22=cpuid
6: mov x0, x22
7: bl lookup_processor_type
8: mov x23, x0
// x23=current cpu_table
9: cbz x23, __error_p
// invalid processor (x23=0)?
10:
11: pgtbl x25, x26, x28
// x25=TTBR0, x26=TTBR1
12: ldr x12, [x23, #CPU_INFO_SETUP]
13: add x12, x12, x28
// __virt_to_phys
14: blr x12
// initialise processor
15:
16: ldr x21, =secondary_data
17: ldr x27, =__secondary_switched
// address to jump to after enabling the MMU
18: b __enable_mmu
19: ENDPROC(secondary_startup)
20:
21: ENTRY(__secondary_switched)
22: ldr x0, [x21]
// get secondary_data.stack
23: mov sp, x0
24: mov x29, #0
25: b secondary_start_kernel
26: ENDPROC(__secondary_switched)
我们重点关注上面16~17行，以及21~26行的__secondary_switched，__secondary_switched会将保存在secondary_data全局变量中的堆栈取出，保存在该CPU的SP中，并跳转到secondary_start_kernel继续执行。思考一下其中的意义：
我们都知道，CPU启动后，需要先配置好堆栈，才能进行后续的函数调用，这里使用的是该CPU idle thread的堆栈。就这么简单吗？当然不是，看一下kernel中“current”指针（获取当前task结构的宏定义）的实现方法：
1: #define current get_current()
2: #define get_current() (current_thread_info()->task)
3:
4:
static inline
struct thread_info *current_thread_info(
void)
5: {
6:
register unsigned long sp asm ("
sp");
7:
return (
struct thread_info *)(sp & ~(THREAD_SIZE - 1));
8: }
9:
有没有豁然开朗的感觉？通过CPU的SP指针，是可以获得CPU的当前task的（这和linux kernel进程管理的实现有关，我们不深究）。也就是说，当CPU SP被赋值为idle thread的堆栈的那一瞬间，当前的上下文已经是idle thread了！！
至于后面的secondary_start_kernel，就比较简单了，使能GIC、Timers，设置CPU为online状态，使能本地IRQ中断。等等。最后，调用cpu_startup_entry，进入cpuidle的loop中，已经和“
Linux cpuidle
framework(1)_概述和软件架构”中描述接上了，自此，CPU UP完成。
4.4 cpu_down流程
cpu_down是cpu_up的反过程，用于将某个CPU从系统中移出。从表面上看，它和cpu_up的过程应该类似，但实际上它的处理过程却异常繁琐、复杂，同时牵涉到非常多的进程调度的知识，鉴于篇幅，本文就不再继续分析了。如果有机会，后面再专门用一篇文章分析这个过程。
另外，前面提到的smpboot有关的内容，也和cpu_down的过程有关，也就不再介绍了。
5. 小结
由本文的分析可知，cpu control有关的过程，其本身的逻辑比较简单，复杂之处在于：与此相关的系统服务（任务、中断、timer等等）的迁移。如果要理解这个过程，就必须有深厚的进程调度、中断管理等背景知识作支撑。不着急，来日方长，有机会我们继续分析。
原创文章，转发请注明出处。蜗窝科技，
www.wowotech.net。
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.xiaopingtou.cn//data/attach/topic/topicKPo7gB.jpg', '推荐 jialin32 的文章《Linux CPU core的电源管理(5)_cpu control及cpu hotplug》','https://www.xiaopingtou.net/article-88737.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
其要点包括：