[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C17C671.3020605@s5r6.in-berlin.de>
Date: Tue, 15 Jun 2010 20:29:05 +0200
From: Stefan Richter <stefanr@...6.in-berlin.de>
To: Tejun Heo <tj@...nel.org>
CC: mingo@...e.hu, awalls@...ix.net, linux-kernel@...r.kernel.org,
jeff@...zik.org, akpm@...ux-foundation.org, rusty@...tcorp.com.au,
cl@...ux-foundation.org, dhowells@...hat.com,
arjan@...ux.intel.com, johannes@...solutions.net, oleg@...hat.com,
axboe@...nel.dk
Subject: Re: [PATCHSET] workqueue: concurrency managed workqueue, take#5
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.
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?
(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.)
--
Stefan Richter
-=====-==-=- -==- -====
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists