Linux内核工作队列探秘-阿里云开发者社区

开发者社区> 开发与运维> 正文

Linux内核工作队列探秘

简介: 作者:陈善佩 马涛

工作队列的节能特性最早由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上。对于前两个函数,任务将会被立即执行;而对于后两个函数,任务需要等待一段时间才会被执行。

绑定工作队列的缺陷
在内核中,一种常见的使用工作队列的场景是处理周期性的工作:不断重复执行队列任务,并由回调函数重新将任务放入队列。下面是一段演示程序:

1. static void foohandler(struct work_struct *work)
2. {
3.    struct delayed_work *dwork = to_delayed_work(work);
4.    /* Do some work here */
5.    queue_delayed_work(system_wq, dwork, 10);
6. }
7. void foo_init(void)
8. {
9.    struct delayed_work *dwork = kmalloc(sizeof(*dwork), GFP_KERNEL);
10.    INIT_DEFERRABLE_WORK(dwork, foo_handler);
11.    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,节能工作队列将会工作得更好。因为在后续调度其中,越来却多的考虑了能源效率。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章