[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B1CDB83.2000600@kernel.org>
Date: Mon, 07 Dec 2009 19:40:03 +0900
From: Tejun Heo <tj@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
CC: torvalds@...ux-foundation.org, awalls@...ix.net,
linux-kernel@...r.kernel.org, jeff@...zik.org, mingo@...e.hu,
akpm@...ux-foundation.org, jens.axboe@...cle.com,
rusty@...tcorp.com.au, cl@...ux-foundation.org,
dhowells@...hat.com, arjan@...ux.intel.com, avi@...hat.com,
johannes@...solutions.net
Subject: Re: [PATCH 16/19] workqueue: reimplement workqueue flushing using
color coded works
Hello,
On 12/07/2009 05:46 PM, Peter Zijlstra wrote:
> A sudden influx of high prio worklets would hold back the completion of
> existing worklets, so simply waiting for a particular colour to deplete
> is going to last a long while.
>
> The barrier semantics I implemented ensured worklets couldn't cross a
> barrier, so if a high prio item got stuck behind a barrier it would
> simply elevate the priority of everything before the barrier, and would
> complete everything before that barrier before running itself.
>
> This insures progress and thereby guarantees completion of flushes.
Hmmm... I haven't really thought about priority aware implementation
but if we're gonna do that with global shared workers, the logical way
to do it would be to have separate workers with higher priority so
that the prioritizing and starvation prevention can be handled by the
schduler as it does for all other tasks. What kind of priorities are
we talking about? How granual?
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