ACPI in Linux ── 传闻与事实Len Brown

Intel Open Source Technology Center

len.brown@intel.com

Translated by Albcamus <albcamus@gmail.com>

概要：

主流的Linux发型版从几年前就开始提供ACPI支持了，但直到今天，Linux社区

中还存在着很多对ACPI的误解。 本文给出并澄清了关于ACPI in Linux的几个最主要的传

闻。

1, 传闻： 在我的笔记本、PC机、服务器上，打开ACPI支持没有什

么好处

当用户不再以传统模式引导，而以ACPI模式引导，他们注意到的第一件事就是，

电源按钮也被软件控制了。 在传统模式下，当按下电源按钮从而切断电源时，对计算机来

说这是个物理的状态改变(断电)；而在ACPI模式下，按下电源按钮会给OS发送中断，从而

使OS能安全关机。 实际上，电源、休眠，和笔记本上盖合拢， 这些事件都被ACPI标准化

了， OS可以把它们映射到自己的处理例程上。

除了把电源按钮的按下事件标准化之外， OS怎样用软件方式切断电源， 也被

ACPI标准化了。 所以，由软件引发的关机，在Linux系统关闭之后，还可以切断电源；而

在传统模式下，必须在Linux关闭后手工按电源按钮断电。

当在ACPI模式运行时， 用户会注意到电池的寿命延长了。 在今天的笔记本上，

要想延长电池寿命， 一个重要的手段就是电源管理。 当处理器空闲，Linux内核的IDLE循

环例程，将利用ACPI的 「CPU空闲的电源状态（CPU idle power states）」(C-states)来

省电。 当处理器部分空闲，Linux的 cpufreq子系统，将利用ACPI的「CPU的性能状态

（performance states）」(P-states)，降低CPU的电压和频率，以达到省电目的。

ACPI和传统模式的其他区别，可能受到用户所在的平台(译按，platform，可能

专指BIOS实现)和GUI界面的影响，这些区别包括：电池低容量警报，发热控制(thermal

control)，以及调用suspend-to-disk或 suspend-to-RAM的能力等等。

使用Intel超线程处理器的用户可能注意到了，超线程只能在ACPI模式下使用，

不能在传统模式下使用。

今天的很多机器有多个处理器，这样的机器使用IO-APIC来把中断源递送到系统

中的各个处理器。 然后，有些机器并没有实现对传统的多处理器规范(Multi-Processor

Specification, MPS)的支持， 因此， 要想在这样的系统上配置 IO-APIC，就只能使用

ACPI。 如果不使用ACPI， IO-APIC就以 XT-PIC的方式工作。

但是，如果我们想更深入的了解ACPI模式和传统模式的区别，就只能转向 ACPI

规范本身。 在ACPI规范之前，最重要的类似规范是APM(Advanced Power Management，

高级电源管理)──除APM外，ACPI还取代了 MPS(Multi-Processor Specification，多

处理器规范)和 PCI IRQ路由规范(PIRQ)。

1.1 ACPI vs. 高级电源管理APM

APM和ACPI这两种规范是互相排斥的。 一个灵活的OS实现可以实现对二者的支

持， 但无法同时激活(enable)二者──因为它们互相排斥。

APM 1.0发布于1992年， Microsoft Windows 3.1提供了对它的支持。 APM规

范的最后更新，也就是1.2版本，是1996年发布的。

ACPI 1.0是从1996年开始开发的，Microsoft的 Windows NT第一个提供了对它

的支持。 在接下来的相当长时间中，Windows更倾向于使用ACPI，但它依然保留对APM的

支持，以便支持老的机器。 从 Windows Vista开始，Microsoft彻底完成了从APM到ACPI

的转换：它不再提供对APM的支持了。

在从APM到ACPI的转换时期， 很多平台供应商删除了对APM的支持， 现在已经

没几家供应商还对APM提供支持了：转换时期已经结束了。

1.1.1 APM概览

APM规范的设计目标是：延长电池寿命； APM试图对OS隐藏一切实现细节，而倾

向于在APM BIOS中实现。

APM定义了系统中五种通用的电源状态： Full On, APM Enabled, APM Standby,

APM Suspend，和Off。 Full On状态没有电源管理， APM Eanbled状态会禁用某些用不着

的设备， APM Standby状态的设计目的是瞬间唤醒(wakeup)系统， APM Suspend可以选择

挂起到 RAM(suspend-to-RAM)，也可以选择挂起到磁盘(hibernate-to-disk)。

APM也为设备定义了类似的电源状态： Device On， Device Power Managed，

Device Lower Power， 和 Device Off。 当处于Device Off状态时，计算机就无法得知设

备的上下文了。 但是，在Device Off时，应该由谁来负责保存和恢复设备呢， 是位于OS

中的APM设备驱动程序， 还是APM BIOS？ 在这一点上APM规范有些含混不清。

APM规范定义了CPU核心的控制状态： Full On， Slow Clock， 和Off。 只要

中断到来，CPU就会马上转入Full On状态。

支持APM的OS，会有一个APM驱动程序，用来和APM BIOS通信。 当APM驱动程

序和APM BIOS建立起通信连结后，它们「一起合作来进行电源管理」，意思是，OS调用

BIOS例程来查询和修改APM BIOS的默认设置， OS以至少每秒一次的频率轮寻 BIOS，看有

没有APM BIOS 事件发生。

APM BIOS可以向 APM驱动程序发送事件。 举例来说，当检测到一段时间的CPU

空闲后，APM BIOS产生一个「System Standby Request Notification」，通知 OS：需要

suspend。 OS接到通知后，必须在一定时间内调用「Set Power Function」函数，否则的

话，BIOS就直接把系统suspend了。 当resume时，APM BIOS产生一个「System Standby

Resume Notification」来通知 OS──对OS来说，此时是更新自己时钟的好时机。

OS还可以禁止 APM向自己发送suspend/resume请求。 取而代之，OS自己决定什

么时候主动要求 APM来执行这些操作。

OS也可以在其IDLE例程中调用APM BIOS，告诉它CPU现在空闲。这样，APM

BIOS就可以降低CPU的频率和电压。

APM BIOS知道机器的AC/DC电源状态， APM驱动程序可以查询 BIOS来获得当前

的电源状态，也可以对AC/DC的改变进行轮询。

APM BIOS知道电池的状态， APM驱动程序可以查询电池的配置和电量，也可以对

「Battery Low Notification」事件进行轮询。

APM为了电源管理，保存了一个硬编码的设备列表，包括显示器、磁盘、并口、

串口、网络适配器、PCMCIA插槽等。 OS可以轮询它们的状态，激活/禁用 APM BIOS对它们

的管理，以及对状态的改变进行轮询。

1.1.2 为什么现在APM不合适了

APM规范是以APM BIOS为中心的。 操作系统的APM驱动程序对APM BIOS进行调

用，就进入了APM BIOS； 此外，系统管理中断(System Management Interrupts, SMI)使

得计算机进入系统管理模式(System Management Mode, SMM)也可以进入 APM BIOS。 APM的

一些部分是必须依赖于SMM的，因为 BIOS需要在没有OS、或者不知道 OS细节的情形下就能

够在CPU上运行。

但事实上，调用BIOS例程对一个OS来说，有点吓人。 每一次调用，都相当于

OS把系统的稳定性交给了BIOS的开发者。 比 BIOS调用更吓人的是SMM，它对OS来说是完

全透明的，出了问题没法 DEBUG。 这二者带来的最大问题是，万一系统的状态并不象 BIOS

的作者预期的那样，那么从BIOS返回到OS时就无法正确恢复状态。

因此，「APM经验」这个词的含义就不太确定：不同的平台各有不同的APM BIOS

实现。

另外，APM规范中包含了一个限制：系统的设备列表是硬编码的。 它是不可扩展

的，比规范本身出现得晚的设备，BIOS将无法识别。

而ACPI的基本思想是，把电源管理的任务交给OS，而不是BIOS。 ACPI把这一

思想称为 OSPM──Operating System-directed configuration and Power Management。

OSPM从来不进入 BIOS，只是它会在内核引导时解析 BIOS ACPI机器语言(ACPI Machine

Language, AML)去访问系统的设备和内存。

ACPI减少了SMM的用场。 但对BIOS作者来说，如果需要，SMM依然可用。

ACPI的 AML语言是可扩展的。 它可以用来描述设备上的资源和能力──即使

ACPI规范制订时根本没有这种设备。 这就给了OS处理各种各样配置机器上的电源管理的能

力。

ACPI 1.0实在1996年年底发布的，而可以说，直到 2000年发布了ACPI 2.0,它

才得到广泛的部署， Microsoft在那年发布了 Windows 2000, 于是APM的时代结束了。

如果你有一台1998或 1999年生产的笔记本，同时支持APM和ACPI，你会发现

APM实现的更成熟，被很好的测试过；而ACPI实现则相对差一些。 就linux来说，现在的

机器都推荐首选 ACPI，但对于上个世纪的机器，则推荐禁用ACPI，并配置上

CONFIG_ACPI_BLACKLIST_YEAR=2000选项。

1.2 多处理器规范(MPS)

MPS 1.1发布于1994年，它的最新版本 MPS 1.4发布于1995年，并在1997年 5

月做了小的修改。 MPS规范的首要目的是把多处理器系统的配置标准化，以便一个OS不做

修改就可以在其上引导和运行。 这样，谁买了遵循 MPS规范的机器，就可以选择已有的操

作系统。

MPS规定系统必须是对称的(symmetric)──所有的处理器、内存和I/O都是平等

的；它还规定了必须要有本地 APIC和 IO APIC。

本地 APIC提供了对 处理器间中断(Inter-Processor Interrupts,IPI)的支持─

─具体来讲，INIT IPI和 STARTUP IPI被用来激活一个处理器(译注：SMP机器引导时，只

有一个处理器执行引导代码，称为引导处理器BP；其他的处理器称为应用处理器AP。BP向

AP发送INIT和 STARTUP IPI，就把这个AP带到了运行状态)。

尽管 MPS规范把遵循它的BIOS称为「MP BIOS」，其代码却跟「APM BIOS」大不

相同。 MP BIOS只是简单地使所有的处理器进入某个已知状态，以便让 OS可以启动它们，

并构建静态的 MP配置数据结构──亦即MP tables──来枚举系统中的处理器和APICs。

MPS规范也规定了一个标准的内存布局，但后来被e820取代了，后者是ACPI规

范的一部分。

MPS规定每个处理器都是平等的，但是当Intel在 Pentium 4中引入超线程技术

后，处理器就不平等了。 如果MPS把超线程的每个虚拟 CPU都做为平等的处理器对待，会

怎么样？──如果一个OS把超线程机器简单的当成 SMP机器，它对任务的调度就做不到最

佳。

MPS 1.4没有被扩展以适应超线程处理器 1。 所以唯一获得超线程处理器的每个

CPU的方法是：由OS分析 ACPI表。

MPS规范还有一个兄弟规范，用来定义在PIC和 IO-APIC模式下如何映射中断线

的，叫 PIRQ规范。

1.3 ACPI vs. PCI IRQ Routers(PIRQ)

IRQ Routers是位于主板上的逻辑设备，用来把物理的IRQ线连接到不同类型的

中断控制器的输入引脚。 Microsoft发布了[PIRQ]，描述了可以被OS看到的PIRQ

routers。 然而对于如何读取和设置 IRQ routers，该规范没有任何说明──相反，它只是

说，Microsoft公司将与芯片组供应商合作，来确保Windows能在它们的芯片组上工作。

ACPI把 PIRQ routers换成了ACPI PCI Interrupt Link Devices， 其实只是对

下列二者做了AML封装： 1) PIRQ tables；2)未文档化的、特定于芯片组的读取/设置方法。

这种方法的优势在于，OS不必了解哪些特定于芯片组的知识，就可以计算出哪条链接可用、

链接目前正连到哪里，以及改变设置。 这里的意思是说，一个遵循ACPI的 OS不需要了解

特定芯片组的知识，就可以对中断进行路由。

1.4 有好处，也有风险

Linux/ACPI子系统庞大又复杂，特别是跟 APM BIOS相比更是如此。 使用ACPI，

也意味着伴随有BUG。 在 2000年之前的系统上尤其如此，因为它往往有成熟的APM实现和

不成熟的ACPI实现。

但工业界基本上都放弃支持那些被ACPI取代了的规范了。 Linux发行版普遍会

提供对ACPI的支持。 所以Linux社区要持续努力的改进其ACPI实现，这对用户很关键。

2 传闻：Suspend to Disk不工作，肯定是ACPI出错了

Linux的 Suspend-to-disk(STD)实现，和ACPI基本没什么关系。 如果你的系统

上STD不工作，你尝试一下acpi=off或 CONFIG_ACPI=n，只有这时STD工作了，你才能假定

这是个与 ACPI相关的问题。

ACPI在 suspend-to-disk过程中的角色，很类似于它在系统引导和系统power-

off时的角色。 不同之处在于，如果 ACPI可用，那么STD使用「platform」方式、而不是

「shutdown」方式来power-off。 这允许更多的设备充当「wakup设备」，把系统从STD状

态（而不是从soft power-off状态）唤醒。

很多最终用户以为 STD和 ACPI是同义词。 原因之一就是，以前Linux曾用

/proc/acpi/sleep来调用STD； 然而为了提供通用的/sys/power/state接口，该方法已经

被废弃了。。

注意，syspend-to-RAM(STR)跟 ACPI的关系要比 STD紧密些， 这是因为睡眠和唤

醒的路径都是ACPI相关的。

无论如何，大部分导致 STD和 STR失败的原因都和ACPI没关系，倒是跟设备驱动

程序有关。 你可以尝试在suspend之前卸载某驱动程序，resume之后再加载它，这样来判

断问题所在。

3 传闻： 笔记本上的按钮不工作，肯定是ACPI的问题

ACPI规范只标准化了 3个按钮：电源按钮，休眠按钮，和上盖合拢。 如果在

ACPI下这 3个按钮不工作，那才真是ACPI的问题。

而键盘上的其他按钮是由各种平台相关的方法来处理的。

首选，如果键盘上的标准按钮（它们是由标准的键盘驱动程序处理的，直接跟

input子系统挂钩）不工作了，不应该责怪 ACPI，因为即使你引导时传入 acpi=off参数，

这个问题还是会存在的。

至于「热键」(hot-keys)的「ACPI问题」 ── 这些是平台相关的按钮，不是由

标准的键盘驱动程序来处理的。

当处于acpi=off模式， 这些键可能通过 SMI/SMM由BIOS来处理； 在ACPI模式，

SMM就被禁用了，这样就可以由OS中的驱动程序来处理这些平台相关的热键。 对windows

来说，供应商一般会保证这一点； 然而对Linux来说却未必，迄今为止没有供应商为 Linux

提供平台相关的热键的驱动程序。

有时侯这些键的确使用ACPI子系统来工作，它们向特定制造商的ACPI设备发送

事件，这就需要特定供应商的ACPI设备驱动程序来接收这些事件，并把它们映射到相关的

动作。

4 传闻： 我的主板上，加上acpi=off能引导，不加就失败了，这是

ACPI的问题

随着多核处理器的普及，SMP系统现在很常见，所有基于x86的SMP系统都有一

个IO-APIC。

但很多笔记本和PC制造商并没有在BIOS包含MPS支持。 当以acpi=off启动时，

系统的IO-APIC就以 8259 PIC方式工作； 因此只有在ACPI模式下，IO-APIC才会激活，所

以很多关于IO-APIC的问题都被怪罪到了ACPI头上。

这种情形下的ACPI和 non-ACPI的区别，其实应该是内核参数 acpi=off和 noapic

的区别──这 2种情况下IO-APIC都会以 8259 PIC方式工作。

但是，为什么这么多系统都存在IO-APIC相关的问题？ 最常见的原因出在周期性

的 HZ定时器身上。 Linux通常使用 8254可编程间隔定时器(译注：Programmable Interval

Timer，即 PIT，原文误作 programmable interrupt timer)来做时钟计数， 该定时器通常

经由IO-APIC的针脚 0或者针脚 2，路由到IRQ0。

Windows系统不使用PIT定时器，它使用IRQ8上的 RTC时钟。 所以当供应商只提

供对 Windows系统的支持时，可能就不会注意到自己的机器因为8254 PIT有问题，无法启

动 Linux。

5 传闻： Linux社区对ACPI规范没有多少影响力

ACPI规范最初是上世纪90年代中期， 由 HP, Intel, Microsoft, Phoenix和

Toshiba一起开发的，它一直在持续改进。 3.0b是 2006年10月发布的。

在该规范的改进过程中，Linux扮演了相当重要的角色。 最新版的ACPI规范包

含了一部分「澄清」──这是Linux社区的直接反馈。

有时侯 Linux上的ACPI在某个领域无法正常工作，原因是ACPI规范中对这个领

域的描述是模糊不清的， 这样会导致 Linux社区的实现是一个样子，而BIOS供应商和

Microsoft的实现是另一个样子。

每当这种情况发生， Intel开源技术中心(Intel Open Source Technology

Center)的 Linux/ACPI团队就直接向 ACPI规范委员会提交「规范澄清」， 然后规范就会被

更新， Linux就做出改动，来遵循改正了的规范。

6 传闻： ACPI的 BUG都是因为 BIOS不遵循规范

当linux实现和支持ACPI时，我们可以把错误分为3类：

1. 因为 BIOS实现违背了ACPI规范，所以导致了Linux的错误

这种情况是因为在Linux也实现了ACPI支持之前， BIOS制造商只能用 Windows来测

试自己的ACPI实现是否正确。 很不幸，使用OS来测试，并不能保证 BIOS的实现是

依从ACPI规范的。 结果就是，很多BIOS实现在Linux上只会「碰巧」能工作，因

为它只测过Windows系统。

而今天，我们有了「Linux-Ready Firmware Developer Kit」(FWKIT)包，这样，

BIOS开发者就可以测试它是否支持Linux。

2. 因为 BIOS开发者和Linux开发者对ACPI规范的理解不一致，导致了Linux/ACPI的错

误

如前面讲的，我们把这类问题看作是Linux的 BUG，修正它，并更新规范。

3. Linux/ACPI实现的BUG

这是纯粹的Linux BUG，就象内核中的其他BUG一样。

这个传闻把很多的错误都归于第1种：BIOS的 BUG。 而事实却如图2所示： 只

有不到10%的Linux/ACPI BUG可以归罪于BIOS。

主要的Linux/ACPI BUG都是第 3类的，Linux实现的问题。

7 传闻： 看起来ACPI代码改变了很多，但效果不佳

当ACPI还是个新鲜事、Linux刚开始支持它时，经常会发生这样的事：改变ACPI

实现代码，修正了一些系统上的问题，却在另一些系统上导致了问题。 老实说，如何能够

避免在已支持的系统上引入 BUG，我们还有很长的路。

Marcelo Tosatti在维护 2.4 Linux，他曾走过来很关心地问我：为什么我们修正

一些系统的BUG时总是弄错其它的系统。 很显然，我们需要一个测试工具来确认对规范的

依从，以预防退步，但目前还没有这个工具。 在我们有这个工具之前，Linux就到了 2.6版

本，而且大多数发行版开始支持ACPI，我们突然有了很多运行Linux/ACPI的用户。

有段时间我们一直通过用户的反馈得知退步，Linus Torvalds责怪我们为什么总

是引入已知的退步，他坚信，即是系统以错误的方式工作，也不应该搞错已经安装了的机器。

当然他是对的，从那时Linux/ACPI团队就把退步当作是优先级最高的问题来处理。

同时，Intel公司的一个团队已经开发出了三个测试套件，今天我们就使用它们

来确认 Linux/ACPI是在持续改进。

1. ACPICA ASL Test Suite (ASLTS)，是在intel.com开源发放的包。 [ACPICA] ASLTS

运行一套超过2,000个ASL测试用例，来测试模拟的ACPICA AML解析器──这个解

析器和在Linux内核中的解析器是同一个。 在这一测试套件的开发期间，有 300多

个问题被发现，现在只有不到 50个尚未解决。 ACPICA的更改，即使可能只是引入小

的退步，也将被取消发放。

2. ACPICA API测试套件，测试和ACPICA核心的交互──也就是OS能看到的。 与

ASLTS类似，API测试也是在模拟环境下进行的。

3. ACPI ABAT──自动化了的基本接受测试(Automated Basic Acceptance Tests)──

它运行在Linux上，测验那些用户看得见的ACPI特性。 ACPI ABAT在 Linux/ACPI的

主页开源发布 2。

最后，你可以在bugzilla.kernel.org检查 BUG的统计信息。

8 传闻： ACPI很慢，因此会影响高性能的cpufreq调节模块，例如

ondemand

的确，BIOS把 AML导出给OS，后者必须用一个AML解析器来分析它，而且分析

AML不能发生在对性能有严格要求的地方。 那么，像高性能的「ondemand」P-state调节，

会每秒钟好几次地进行P-state转换，ACPI怎么能适合它呢？

答案是，AML是用来分析 ACPI表的，以告诉 cpufreq：ondemand需要从哪些状态

转换。 然后ondemand就实现它自己的run-time的策略，不再涉及 ACPI了。

上面的规律有个例外情形：平台可能会在运行时改变P-states的个数。 相对来

说这很少见，一般发生在AC->DC转换时，或者严重的过热时。 这种情形下，ACPI重新估计

P-states列表，并通知 cpufreq有什么新的状态可用了；cpufreq回应该变化后，又产生自

己的run-time策略，不在涉及 ACPI了。

9 传闻： speedstep-centrino是本地的，因此比基于ACPI

的'acpi-cpufreq'快

要想改变处理器的频率和电压，OS可以有两种方式：1, 直接写本地的 MSR寄存

器(Model-Specific Registers)，也可以访问一个I/O地址。 这二者的效率相差很大，访

问 IO地址的方式要差很多，特别是它有可能trap到 SMM状态。

所以社区开发了speedstep-centrino，它是把P-states表硬编码的、基于CPUID

指令和本地 MSR寄存器的cpufreq驱动程序。 Speedstep-centrino不需要ACPI。

在那个时期，使用acpi-cpufreq而不用speedstep-centrino就意味着使用了低

效的IO访问，可以说题目中的传闻是对的──但是后来有两件事发生了变化：

1. speedstep-centrino的硬编码的P-states表很难维护，所以它也加入了对ACPI的支

持，这样它可以首选查询 ACPI tables，而把硬编码的tables作为备份数据。

2. Intel发布了「Intel Processor Vendor-Specific ACPI Interface

Specification」，该规范使得厂商公开一些bits信息，这样一个ACPI实现也可以

访问本地的 MSR寄存器，所以访问本地 MSR寄存器的方法也被添加到acpi-cpufreq

中了。

结果就是，这二者都可以和ACPI交互，也都可以和 MSRs交互。 speedstep-

centrino还保留了它的硬编码的表，acpi-cpufreq依然可以在OS要求的时候访问 IO地址。

最近，acpi-cpufreq被选作二者中推荐的一个，而speedstep-centrino已经准

备从源代码树中删除了(译注：参看 Documentation/feature-removal-schedule.txt)

10 传闻： CPU空闲的电源状态，越多越好

用户可能观察/proc/acpi/processor/*/power的系统C-states，猜测 C-states

越多，就会越省电。 如果他们还看了Intel CoreTM Duo处理器的手册并试图和这些上面文

件中的这些状态联系起来，就更加认为这个猜测是合理的。

然而，由于某些限制，硬件的C-states到（Linux能看到的）ACPI的 C-staes的

映射是任意的。 只有下列跟 C-states有关：节省的电量，唤醒处理器的延迟。 有些系统

导出很多C-states，有些导出很少的C-states但却在这些表面的背后实现了省电技术。

Dynamic Cache Sizing就是这样的一个例子。 它不直接受OS或 C-states的控

制，然而当CPU发现到了深度的C-states(译注：亦即系统负荷很低)，它就冲刷更多的

Cache； 当系统非常空闲，则 CPU就冲刷全部的Cache，然后完全断电。 该特性在CPU中的

实现是否受到处给OS的 C-states数目的影响？用户无法知道──它完全是在这些的背后、

在CPU的固件中实现的。

11 传闻： 调节(Throttling)CPU肯定能省电，且延长电池寿命

能量 = 功率 * 世间， 也就是说， [瓦特-小时] = [瓦特] * [小时数]

例如，处理器被调节成以一半的时钟频率运行，因此耗费一半的电，但它要花两

倍的时间来做同样的事。 耗费的能量是一样的，只不过把时间延长了。 能量/工作量 是个

常数。

也有些次要的因素使得这个传闻是对的。 举个例子，电池总不是理想的，低功

率的时候它一般会提供更多的电。

此外，有风扇的系统需要能量来转动风扇。如果系统在完成工作的时候一直没有

过热，成功的保持风扇低速转动(或者干脆不转)，那么确实同样的工作量会消耗更少的电。

注意这里讨论的处理器的频率调节(ACPI的 T-states)不要和性能状态(ACPI的 P-

states)搞混。 由于P-states同时减少电压和频率，深度的P-state的确会使处理器有更

高效的 能量/工作量 比率，降低 能量/工作量 的值。

12 传闻： 我无法对改进 Linux/ACPI做贡献

最后这个传闻，是由于ACPICA的存在造成的。

ACPICA(ACPI Component Architecture)是 Intel提供的一个参考实现，实现了

ACPI解析器和不须让 OS知道的代码。 除Linux外， BSD、SolarisTM和其他操作系统也把

自己的ACPI实现基于ACPICA之上，因此，Intel公司掌握着ACPICA的版权，同时以BSD和

GPL协议发放。

在linux内核中，drviers/acpi/目录下有160个ACPICA文件，当社区提交针对

这些文件的补丁，Linux/ACPI团队就会请求补丁的作者把代码的版权归于Intel，以便同时

以GPL和 BSD发放（而不是仅用GPL）。这样，Intel可以把代码分享给其他ACPICA用户，

而不用维护多个分支。

对开源贡献者来说，ACPICA的版权不是问题；但由于它并不直接等同于GPL，它

还要求一些其他的许可，所以造成了这种错误印象：我们不欢迎补丁。

另外，drivers/acpi/目录下有 40个GPL的文件，它们比较受社区欢迎，包含着

特定于Linux的代码，把ACPICA核心当成一个「黑盒子」。

提交补丁只是贡献方式的一种。 如前所述，Linux/ACPI的一个重要任务就是防

止在工业界各种机器的BIOS上出现退步。 在广泛的不同系统上测试 ACPI相关功能的人越

多，对开发者来说做出改进就越容易。

你的系统以ACPI方式启动，应该比以acpi=off方式启动更好。另外，ACPI支持

的电源管理特性，如 suspend-to-RAM和CPU的电源管理，应该是──而且一直是──正常

工作的。

如果用户能帮忙确认自己的系统上Linux的 ACPI实现能正确工作(without

workarounds，即不用绕过问题)， 这对社区来说是个巨大的帮助。 当用户报告退步，

BUG，和帮忙测试补丁，他们就在帮忙，为 Linux上的ACPI实现做了有益的推动。

13 结论

请忘掉你几年前的对Linux/ACPI的印象吧。 Linux上的ACPI并不神秘，现在各

大发行版都支持它，它必将越来越好。 请确认你机器上的ACPI相关的特性都正确工作，如

果有问题，请大声报怨，敦促开发者解决掉问题 3。

社区对Linux上的ACPI有着高标准的要求，持续得把它做到最好。

注释：

────────────────

注1： 有些BIOS提供SETUP选项来枚举超线程处理器的每个虚拟 CPU，以 MPS的方式。但这

只是个非标准的特性。

注 2： http://acpi.sourceforge.net

注 3： 从linux-acpi@vger.kernel.org入手，了解Linux/ACPI相关的问题。

参考

[ACPI] Hewlett-Packard, Intel, Microsoft, Phoenix,

Toshiba, Advanced Configuration and Power

Interface, Revision 3.0b, October, 2006.

http://www.acpi.info

[ACPICA] Intel, ACPI Component Architecture,

http://www.intel.com/technology/

iapc/acpi/downloads.htm

[APM] Intel,Microsoft Advanced Power Management

BIOS Interface Specification, Revision 1.2,

February,1996.

http://www.microsoft.com/whdc/archive/apm_12.mspx

[FWKIT] Linux-Ready Firmware Developer Kit,

http://www.linuxfirmwarekit.org

[MPS] Intel, MultiProcessor Specification, Version

1.4, May, 1997. http://www.intel.com/

design/intarch/MANUALS/242016.htm

[PIRQ] Microsoft, PCI IRQ Routing Table

Specification, Version 1.0, February, 1996.

http://www.microsoft.com/whdc/

archive/pciirq.mspx