Hey Tejun,
On 27 April 2013 00:41, Tejun Heo tj@kernel.org wrote:
Hey, Viresh.
It's already too late for the upcoming merge window, but things generally look good to me and I'll apply the patchset once wq/for-3.11 opens. One nitpick tho.
Obviously. I understand this and agree with you on it. It should go in 3.11 now.
On Thu, Apr 25, 2013 at 09:13:44AM +0530, Viresh Kumar wrote:
workqueue.power_efficientWorkqueues can be performance or power-oriented.Currently, most workqueues are bound to the CPU they^^^^ per-cpu would be better
were created on. This gives good performance (due tocache effects) at the cost of potentially waking upotherwise idle cores just to process some work. To savepower, we can allow the work to be rescheduled on a corethat is already awake.The above description is confusing to me. As have been discussed multiple times before, per-cpu workqueue in itself doesn't wake up the CPU physically. The timer may but per-cpu workqueue doesn't. It was confusing when this patchset was first posted and the above phrasing is still confusing. What the patchset tries to do is preventing the scheduler from perceiving the CPU as active due to the activated worker thread pinned to that CPU, right? The knob doesn't really do anything about waking up the processor in itself. It just avoids feeding the scheduler with noisy activation events and allows it to allocate work item execution according to the scheduler's view of CPU active/idleness. As the scheduler has longer / larger scope of overall CPU activities and means to regulate them, this leads to more power-efficient allocation of work item executions, right? It'd be really great if the descriptions and the comment above the flag makes this abundantly clear because it's not something too apparent.
Whatever you wrote above confused me even more :) This is what i had in my mind until now. Its not about per-cpu workqueue.
Lets take example of system_wq. It doesn't have WQ_UNBOUND flag set. Now if we call queue_work_on() with cpu x and sytem_wq, then work will execute on cpu x. If we call queue_work() then it will queue the work on local cpu.
At this time local cpu may be busy or idle (Atleast according to scheduler). We don't want a idle cpu (From schedulers perspective) to be used for running this work's handler due to two reasons. - idle cpu may be in WFI or deeper idle states and so we can avoid waking it up. - We will make idle cpu look busy and so other kernel stuff may be scheduled on it now. But we could have kept it idle for a long time.
And what timer are you talking about? I am not talking about deffered work only, but normal work too.
I might have wrongly phrased some part of my patch (maybe used workqueue instead of work), will fix that up.
-- viresh