Re: [RFC PATCH 11/12] workqueue: add WQ_CPU_INTENSIVE to system_long_wq
Hello, Lai. On Fri, Sep 28, 2012 at 04:06:48PM +0800, Lai Jiangshan wrote: > But does we need a stand-alone workqueue for work_on_cpu() as it is original > introduced? (2d3854a3) Given how work_on_cpu() is used currently, I don't think we need that. What we need to do is removing the remaining flush_scheduled_work() users and trigger WARN if somebody tries to flush one of the system workqueues. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 11/12] workqueue: add WQ_CPU_INTENSIVE to system_long_wq
Hello, Lai. On Fri, Sep 28, 2012 at 04:06:48PM +0800, Lai Jiangshan wrote: But does we need a stand-alone workqueue for work_on_cpu() as it is original introduced? (2d3854a3) Given how work_on_cpu() is used currently, I don't think we need that. What we need to do is removing the remaining flush_scheduled_work() users and trigger WARN if somebody tries to flush one of the system workqueues. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 11/12] workqueue: add WQ_CPU_INTENSIVE to system_long_wq
Hi, Tejun On 09/27/2012 02:38 AM, Tejun Heo wrote: > On Thu, Sep 27, 2012 at 01:20:42AM +0800, Lai Jiangshan wrote: >> works in system_long_wq will be running long. >> add WQ_CPU_INTENSIVE to system_long_wq to avoid these kinds of works occupy >> the running wokers which delay the normal works. >> >> if system_long_wq is designed for only sleep-long works, not running-long >> works, >> this patch makes no sense. > > There "long" doesn't mean it's gonna consume a lot of CPU cycles, so > it should contribute to concurrency management. The plan is to remove > system_long_wq once we got rid of flushing of system_wq via > flush_scheduled_work() and directly through flush_workqueue(). I > think we're pretty close, so let's not add more usage of it. > OK. But does we need a stand-alone workqueue for work_on_cpu() as it is original introduced? (2d3854a3) Thanks, Lai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 11/12] workqueue: add WQ_CPU_INTENSIVE to system_long_wq
Hi, Tejun On 09/27/2012 02:38 AM, Tejun Heo wrote: On Thu, Sep 27, 2012 at 01:20:42AM +0800, Lai Jiangshan wrote: works in system_long_wq will be running long. add WQ_CPU_INTENSIVE to system_long_wq to avoid these kinds of works occupy the running wokers which delay the normal works. if system_long_wq is designed for only sleep-long works, not running-long works, this patch makes no sense. There long doesn't mean it's gonna consume a lot of CPU cycles, so it should contribute to concurrency management. The plan is to remove system_long_wq once we got rid of flushing of system_wq via flush_scheduled_work() and directly through flush_workqueue(). I think we're pretty close, so let's not add more usage of it. OK. But does we need a stand-alone workqueue for work_on_cpu() as it is original introduced? (2d3854a3) Thanks, Lai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 11/12] workqueue: add WQ_CPU_INTENSIVE to system_long_wq
On Thu, Sep 27, 2012 at 01:20:42AM +0800, Lai Jiangshan wrote: > works in system_long_wq will be running long. > add WQ_CPU_INTENSIVE to system_long_wq to avoid these kinds of works occupy > the running wokers which delay the normal works. > > if system_long_wq is designed for only sleep-long works, not running-long > works, > this patch makes no sense. There "long" doesn't mean it's gonna consume a lot of CPU cycles, so it should contribute to concurrency management. The plan is to remove system_long_wq once we got rid of flushing of system_wq via flush_scheduled_work() and directly through flush_workqueue(). I think we're pretty close, so let's not add more usage of it. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 11/12] workqueue: add WQ_CPU_INTENSIVE to system_long_wq
works in system_long_wq will be running long.
add WQ_CPU_INTENSIVE to system_long_wq to avoid these kinds of works occupy
the running wokers which delay the normal works.
if system_long_wq is designed for only sleep-long works, not running-long works,
this patch makes no sense.
Signed-off-by: Lai Jiangshan
---
kernel/workqueue.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 89fd1b2..ccb1d60 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3850,7 +3850,7 @@ static int __init init_workqueues(void)
system_wq = alloc_workqueue("events", 0, 0);
system_highpri_wq = alloc_workqueue("events_highpri", WQ_HIGHPRI, 0);
- system_long_wq = alloc_workqueue("events_long", 0, 0);
+ system_long_wq = alloc_workqueue("events_long", WQ_CPU_INTENSIVE, 0);
system_unbound_wq = alloc_workqueue("events_unbound", WQ_UNBOUND,
WQ_UNBOUND_MAX_ACTIVE);
system_freezable_wq = alloc_workqueue("events_freezable",
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 11/12] workqueue: add WQ_CPU_INTENSIVE to system_long_wq
works in system_long_wq will be running long. add WQ_CPU_INTENSIVE to system_long_wq to avoid these kinds of works occupy the running wokers which delay the normal works. if system_long_wq is designed for only sleep-long works, not running-long works, this patch makes no sense. Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com --- kernel/workqueue.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 89fd1b2..ccb1d60 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -3850,7 +3850,7 @@ static int __init init_workqueues(void) system_wq = alloc_workqueue(events, 0, 0); system_highpri_wq = alloc_workqueue(events_highpri, WQ_HIGHPRI, 0); - system_long_wq = alloc_workqueue(events_long, 0, 0); + system_long_wq = alloc_workqueue(events_long, WQ_CPU_INTENSIVE, 0); system_unbound_wq = alloc_workqueue(events_unbound, WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE); system_freezable_wq = alloc_workqueue(events_freezable, -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 11/12] workqueue: add WQ_CPU_INTENSIVE to system_long_wq
On Thu, Sep 27, 2012 at 01:20:42AM +0800, Lai Jiangshan wrote: works in system_long_wq will be running long. add WQ_CPU_INTENSIVE to system_long_wq to avoid these kinds of works occupy the running wokers which delay the normal works. if system_long_wq is designed for only sleep-long works, not running-long works, this patch makes no sense. There long doesn't mean it's gonna consume a lot of CPU cycles, so it should contribute to concurrency management. The plan is to remove system_long_wq once we got rid of flushing of system_wq via flush_scheduled_work() and directly through flush_workqueue(). I think we're pretty close, so let's not add more usage of it. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
