工作队列的节能特性最早由3.11内核引入，此后，50多个子系统和设备驱动开始使用它。而节能工作队列则被广泛用于手持设备（如平板电脑，智能手机）。ARM平台上，在Android系统中使用节能工作队列，可以显著降低能源消耗。
在Linux kernel中，工作队列是常见的延后执行机制，经常出现在异步执行上下文中。上下文由内核工作线程提供，当有任务被放入队列（入队操作）时，工作线程将会被唤醒。内核实现时，工作队列由strut workqueue_struct表示，而任务由strut work_struct表示。work_struct中包含一个回调函数，该函数将会被工作线程调用，以表示任务被执行。一旦工作队列上的所有任务执行完毕，工作线程又继续睡眠。
下面是工作队列相关的常见API：
bool queue_work(...); bool queue_work_on(...); bool queue_delayed_work(...); bool queue_delayed_work_on(...);
queue_work_on()和queue_delayed_work_on()指定了任务由哪个cpu上的工作线程执行，另两个函数允许任务运行在任意cpu上。对于前两个函数，任务将会被立即执行；而对于后两个函数，任务需要等待一段时间才会被执行。
绑定工作队列的缺陷
在内核中，一种常见的使用工作队列的场景是处理周期性的工作：不断重复执行队列任务，并由回调函数重新将任务放入队列。下面是一段演示程序：
static void foohandler(struct work_struct *work) { struct delayed_work *dwork = to_delayed_work(work); /* Do some work here */ queue_delayed_work(system_wq,dwork,10); } voidfoo_init(void) { struct delayed_work *dwork = kmalloc(sizeof(*dwork), GFP_KERNEL); INIT_DEFERRABLE_WORK(dwork,foo_handler); queue_delayed_work(system_wq,dwork,10); }
读者可能会认为，任务将会被任意cpu执行（由调度器选出一个最合适的cpu）。遗憾的是，这不完全正确。工作队列机制倾向于将任务放入local cpu（即，执行queue_delayed_work()的那个cpu），除非local cpu被wq_unbound_cpumask屏蔽了。举个例子，在8核平台上，上面演示程序中的回调函数总是在一个cpu上执行，尽管该cpu处于idle状态且存在其它cpu处于运行状态。
wq_unbound_cpumask表示可以执行“工作队列任务”的cpu集合，注意，只有当该任务没有通过API(xxx_work_on())指定到某个特定的cpu时,该掩码才生效。该掩码可以通过 /sys/devices/virtual/workqueue/cpumask设置。
从节能的角度看，一个正在执行正常程序的cpu被中断，然后执行工作队列任务，这是可接受的。反之，如果唤醒一个处于idle状态的cpu，然后仅仅更新时钟和将任务放入队列，这将消耗更多能源。cpu绑定有时并不能带来好的性能，因为被绑定的cpu并不一定是调度器认为的负载最轻的cpu，此时调度器不能进行负载均衡。
工作队列的节能特性
默认情况下，工作队列的节能特性是关闭的。使能该特性有两种方式：
- 内核启动参数 workqueue.power_efficient=true
- 编译内核时打开开关 CONFIGWQPOWER_EFFICIENT = y
一旦使能节能模式，我们就可以在调用 alloc_workqueue() 时传入WQ_POWER_EFFICIENT标志，建立节能工作队列。内核中还维护了两个全局的节能工作队列：system_power_efficient_wq 和 system_freezable_power_efficient_wq，当用户不想建立自己私有的队列时，可以使用它们。
不同于之前的local cpu策略，节能模式下，任务入队时，总是由调度器提供一个target cpu，然后将任务放入target cpu上的工作队列。因此，现在任务可以在不同的cpu执行了。
不幸的是，这并不意味着调度器总是选择一个最优的cpu去执行工作队列任务。调度器的调度算法非常复杂，但总体上，它在考虑cache亲和性的基础上，倾向于选择一个负载最轻的cpu。如果，工作队列任务没有被快速执行完，任务还有可能会被调度器迁移到别的cpu上。
节能特性的实现依赖于cpu调度器，但cpu调度器更主要的设计点是性能，其次才在调度策略中加入了能效方面的考虑。因此，当前实现的节能工作队列显然没有采用最优的节能策略，但它在能效方面确实表现得更好了。
很自然的，我们会想到，是否所有的工作队列都应该工作在节能模式下呢？节能工作队列有一个明显的缺点：每次执行任务都在不同的cpu上，cache亲和性被破坏，可能会导致大量cache miss（取决于任务的访存特性），这会显著降低性能。但有的时候，队列任务对cache miss不敏感，调度器的负载均衡操作反而能显著降低队列任务的响应延迟。考虑到上述两方面，在使用节能队列时需要仔认真地评估。
测试数据
在32-bit ARM big.LITTLE平台上运行benchmark，该平台具有4个Cortex A7核和4个Cortex A15核。除了用aplay在后台播放音乐外，整个系统没有其它负载。测试内核采用Linaro公司的ubuntu-devel版本，此外还打了一些调度器补丁。测试结果显示，节能工作队列的能源效率平均提高15.7%。具体数据如下：
Vanilla kernel + Vanilla Kernel+ scheduler patches + scheduler patches power-efficient wq A15 cluster 0.322866 0.2289042 A7 cluster 2.619137 2.2514632 Total 2.942003 2.4803674
如果使用upstream kernel，节能工作队列将会工作得更好。因为在后续调度其中，越来却多的考虑了能源效率。
—— 完 ——
加入龙蜥社群
加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】拉你入群；加入钉钉群：扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥OpenAnolis社区交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！
龙蜥社区钉钉交流群 龙蜥社区-小龙
关于龙蜥社区
龙蜥社区是由企事业单位、高等院校、科研单位、非营利性组织、个人等按照自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于2020年9月，旨在构建一个开源、中立、开放的Linux上游发行版社区及创新平台。
短期目标是开发Anolis OS作为CentOS替代版，重新构建一个兼容国际Linux主流厂商发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。
龙蜥OS 8.4已发布，支持x86_64和ARM64架构，完善适配Intel、飞腾、海光、兆芯、鲲鹏芯片。
欢迎下载：https://openanolis.cn/download
加入我们，一起打造面向未来的开源操作系统！
