[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C1B1CF5.9020900@kernel.org>
Date: Fri, 18 Jun 2010 09:15:01 +0200
From: Tejun Heo <tj@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Joel Becker <Joel.Becker@...cle.com>, mingo@...e.hu,
awalls@...ix.net, linux-kernel@...r.kernel.org, jeff@...zik.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,
Wolfram Sang <w.sang@...gutronix.de>
Subject: Re: Overview of concurrency managed workqueue
On 06/18/2010 01:56 AM, Andrew Morton wrote:
> On Thu, 17 Jun 2010 16:25:03 -0700
> Joel Becker <Joel.Becker@...cle.com> wrote:
>
>> On Thu, Jun 17, 2010 at 04:14:12PM -0700, Andrew Morton wrote:
>>> flush_workqueue() sucks. It's a stupid, accidental,
>>> internal-implementation-dependent interface. We should deprecate it
>>> and try to get rid of it, migrating to the eminently more sensible
>>> flush_work().
>>>
>>> I guess the first step is to add a dont-do-that checkpatch warning when
>>> people try to add new flush_workqueue() calls.
>>>
>>> 165 instances tree-wide, sigh.
>>
>> What would the API be for "I want this workqueue emptied before
>> I shut this thing down?"
>
> Um, yeah. flush_workqueue() is legitimate. I was thinking of
> flush_scheduled_work() - the one which operates on the keventd queue.
With cmwq, each wq now costs much less, so we should be able to
convert them to use their own workqueues without too much problem and
deprecate flushing of system workqueues.
Thanks.
--
tejun
--
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