Re: [PATCHSET] workqueue: concurrency managed workqueue, take#5

From: Tejun Heo
Date: Tue Jun 15 2010 - 14:41:57 EST


On 06/15/2010 08:29 PM, Stefan Richter wrote:
> Tejun Heo wrote:
>> This is the fifth take of cmwq (concurrency managed workqueue)
>> patchset. It's on top of v2.6.35-rc3 + sched/core patches. Git tree
>> is available at
>> git:// review-cmwq
> A comment and a question:
> As a driver maintainer, I would find it helpful if the WQ_flags in
> include/linux/workqueue.h and/or __create_workqueue_key() in
> kernel/workqueue.c (or its wrappers in include/linux/workqueue.h) were
> better documented.

Sure, it can definitely be improved.

> How about the global workqueue, i.e. schedule_work() and friends? At
> your current review-cmwq head, they use system_wq, not system_nrt_wq.
> But doesn't have the present global workqueue WQ_NON_REENTRANT
> semantics? In fact, don't have _all_ workqueues WQ_NON_REENTRANT
> semantics presently? If so, a good deal of existing users probably
> relies on non-reentrant behaviour. Or am I thoroughly misunderstanding
> the meaning of WQ_NON_REENTRANT?

Yeah, it's a bit confusing. :-( The current workqueue semantics is
non-reentrant on the same cpu but reentrant on different cpus.
WQ_NON_REENTRANT is non-reentrant regardless of cpu, so it's stronger
guarantee than before. To summarize,

WQ_SINGLE_CPU < current ST == WQ_SINGLE_CPU + max in_flight of 1.

> (Sorry if this had been discussed before; I followed the discussions of
> some of your previous submissions but not all. And PS, I am eagerly
> awaiting for this to go into the mainline.)

Ah, yeah, after ten month, I'm pretty eager too. :-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at