Re: [PATCH 16/19] workqueue: reimplement workqueue flushing usingcolor coded works

[Tejun Heo]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/