https://lwn.net/Articles/731052/

Don’t look at me, please!

– 雏雁

节能工作队列

工作队列的节能特性最早由3.11内核引入,此后,50多个子系统和设备驱动开始使用它。节能工作队列被广泛用于手持设备(如平板电脑,智能手机)。ARM平台上,在Android系统中使用节能工作队列,可以显著降低能源消耗。

在Linux kernel中,工作队列是常见的延后执行机制,经常出现在异步执行上下文中。上下文由内æ ¸工作线程提供,当有任务被放入队列(入队操作)时,工作线程将会被唤醒。内核实现时,工作队列由strut workqueue_struct表示,而任务由strut work_struct表示。work_struct中包含一个回调函数,该函数将会被工作线程调用,以表示任务被执行。一旦工作队列上的所有任务执行完毕,工作线程又继续睡眠。

下面是工作队列相关的常见API:

bool queue_work(struct workqueue_struct *wq, struct work_struct *work);
    bool queue_work_on(int cpu, struct workqueue_struct *wq, struct work_struct *work);
    bool queue_delayed_work(struct workqueue_struct *wq, struct delayed_work *dwork, 
		    			    unsigned long delay);
bool queue_delayed_work_on(int cpu, struct workqueue_struct *wq, 
	    			       struct delayed_work *work, unsigned long delay);

queue_work_on()和queue_delayed_work_on()指定了任务由哪个cpu上的工作线程执行,另两个函数允许任务运行在任意cpu上。对于前两个函数,任务将会被立即执行;而对于后两个函数,任务需要等待一段时间才会被执行。

绑定工作队列的缺陷

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

static void foo_handler(struct work_struct *work)
    {
	            struct delayed_work *dwork = to_delayed_work(work);
		     
		    	/* Do some work here */
		     
		    	queue_delayed_work(system_wq, dwork, 10);
			    }
 
void foo_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,此时调度器不能进行负载均衡。

工作队列的节能特性

默认情况下,工作队列的节能特性是关闭的。使能该特性有两种方式:

  1. 内核启动参数 workqueue.power_efficient=true
  2. 编译内核时打开开关 CONFIG_WQ_POWER_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,节能工作队列将会工作得更好。因为在后续调度其中,越来却多的考虑了能源效率。