Messages in this thread | | | Date | Tue, 15 Jun 2010 20:40:56 +0200 | From | Tejun Heo <> | Subject | Re: [PATCHSET] workqueue: concurrency managed workqueue, take#5 |
| |
Hello,
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://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.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,
current MT == !WQ_NON_REENTRANT < WQ_NON_REENTRANT < 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. :-)
Thanks.
-- tejun
| |