pm_wq work queue is used for runtime suspend/resume work, these functions are not bound to run on specific CPUs. Having unbounded type will reduce the waiting time.
Signed-off-by: Sanjay Singh Rawat sanjay.rawat@linaro.org ---
Need to test on a full runtime supported hardware --- kernel/power/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/power/main.c b/kernel/power/main.c index 1d1bf63..8212528 100644 --- a/kernel/power/main.c +++ b/kernel/power/main.c @@ -622,7 +622,7 @@ EXPORT_SYMBOL_GPL(pm_wq);
static int __init pm_start_workqueue(void) { - pm_wq = alloc_workqueue("pm", WQ_FREEZABLE, 0); + pm_wq = alloc_workqueue("pm", WQ_FREEZABLE | WQ_UNBOUND, 0);
return pm_wq ? 0 : -ENOMEM; }
On 25 March 2014 16:05, Sanjay Singh Rawat sanjay.rawat@linaro.org wrote:
pm_wq work queue is used for runtime suspend/resume work, these functions are not bound to run on specific CPUs. Having unbounded type will reduce the waiting time.
How?
On Tuesday 25 March 2014 04:10 PM, Viresh Kumar wrote:
On 25 March 2014 16:05, Sanjay Singh Rawat sanjay.rawat@linaro.org wrote:
pm_wq work queue is used for runtime suspend/resume work, these functions are not bound to run on specific CPUs. Having unbounded type will reduce the waiting time.
How?
With unbound type the next worker can be scheduled on other CPUs, while current CPU is busy servicing current worker
On 25 March 2014 16:20, Sanjay Singh Rawat sanjay.rawat@linaro.org wrote:
With unbound type the next worker can be scheduled on other CPUs, while current CPU is busy servicing current worker
Its not that plain or simple. This flag only decides where the work is going to be queued. i.e. at the time we have added it and not the time the work has fired.
And the scheduler would try to find the best possible CPU for running this task and that may turn out to be the same CPU as well.. There is no guarantee here.
I am not against the patch as I think it is useful enough, but the reasoning needs to be more strong, backed by some experiments.
Also for such small patches (i.e. patches which wouldn't draw much criticism), please use LKML directly. We at Linaro don't have any control over many kernel frameworks and it would be better if we discuss things more openly.
Though some typical patches might require a post to linaro-kernel first..
-- viresh
On Tuesday 25 March 2014 07:27 PM, Viresh Kumar wrote:
On 25 March 2014 16:20, Sanjay Singh Rawat sanjay.rawat@linaro.org wrote:
With unbound type the next worker can be scheduled on other CPUs, while current CPU is busy servicing current worker
Its not that plain or simple. This flag only decides where the work is going to be queued. i.e. at the time we have added it and not the time the work has fired.
Ok. This fits in this scenario, runtime PM clients queue the suspend/resume/idle task dynamically based on activity
And the scheduler would try to find the best possible CPU for running this task and that may turn out to be the same CPU as well.. There is no guarantee here.
I am not against the patch as I think it is useful enough, but the reasoning needs to be more strong, backed by some experiments.
Yes need to have some stats, as i have few clients on panda i think it will not show much difference and so sent as RFC. I will try to get some stats.
Also for such small patches (i.e. patches which wouldn't draw much criticism), please use LKML directly. We at Linaro don't have any control over many kernel frameworks and it would be better if we discuss things more openly.
Though some typical patches might require a post to linaro-kernel first..
-- viresh
linaro-kernel@lists.linaro.org
-
Sanjay Singh Rawat -
Viresh Kumar