Re: Overview of concurrency managed workqueue

[Tejun Heo <tj@kernel.org>]

Hello,

On 06/18/2010 07:02 PM, Andrew Morton wrote:
> um.  We've *already* engineered a mechanism which serves the
> requirements which we've been discussing.  Then Tejun came along,
> called it "niche" and busted it!

Andrew, can we turn down dramatization a little bit?  I'll try to
explain my viewpoint again, hopefully in clearer manner.

Workqueue is primarily an async mechanism.  It's designed to be that
way and most of its current users don't care that much about execution
priority.  As everything else in the kernel, it started simple and
continued to evolve.  Up until now, workqueue - thread association has
been largely fixed and it naturally grew some number of users which
depended on that property.  Whether you like the term "niche" or not,
they are few by large proportion.

Please note that such association isn't something workqueue strives to
achieve.  For example, tryinig to exploit the association on MT
workqueue will be cumbersome over suspend/resume cycles and there's no
provision to manage such events.

Workqueues have become quite popular and grew a lot of users.
Compounded by the increasing number of CPU cores, it's also showing
various limitations, some of which affect ease of use while others
scalability or unexpectedly long latencies.  Many of these issues for
most workqueue users can be addressed by sharing workers and managing
work execution centrally, which is what cmwq does.

Sharing workers does cause problems for users which have assumed fixed
workqueue - thread association, but as mentioned earlier, they're few
and converting them to directly use kthread or a (yet non-existing)
facility which guarantees fixed thread association wouldn't be
difficult.

So, it seems logical to move those few cases over to kthread or a new
facility and improve workqueue for the majority of users.  I'm not
planning on "busting" anything.  All such users of course will be
converted so that they keep working properly.

> Oh well.  Kernel threads should not be running with RT policy anyway. 
> RT is a userspace feature, and whenever a kernel thread uses RT it
> degrades userspace RT qos.  But I expect that using RT in kernel
> threads is sometimes the best tradeoff, so let's not pretend that we're
> getting something for nothing here!

Such use is limited to ST workqueues and I can write up a simple
wrapper around kthread in a few hundred lines if necessary.  So, yes,
we're losing one way of using ST workqueues but it sure wasn't very
popular way to use it and it can easily be replaced.

Thanks.

-- 
tejun