lkml.org 
[lkml]   [2009]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: workqueue thing


On Wed, 23 Dec 2009, Tejun Heo wrote:
>
> So, if we can have a mehanism which can solve these issues, it's an
> obvious plus. Shifting complexity out of peripheral code to better
> crafted and managed core code is the right thing to do and it will
> shift a lot of complexity out of peripheral codes.

I really think this is key. I don't think Peter really has worked much
outside of very core code (direct CPU-related stuff), and hasn't seen the
kind of annoying problems our current workqueue code has.

Half the kernel is drivers. And 95% of all workqueue users are those
drivers.

Workqueues generally aren't about heavy CPU usage, although some workqueue
usage has scalability issues. And the most common scalability problem is
not "I need more than one CPU", but often "I need to run even though
another workqueue entry is blocked on IO" - iow, it's not about lacking
CPU power, it's about in-fighting with other workqueue users.

That said, if we can improve on this further, I'd be all for it. I'd love
to have some generic async model that really works. So far, our async
models have tended to not really work out well, whether they be softirq's
or kernel threads (many of the same issues: some subsystems start tons of
kernel threads just because one kernel thread blocks, not because you need
multi-processor CPU usage per se). And AIO/threadlets never got anywhere
etc etc.

Linus


\
 
 \ /
  Last update: 2009-12-23 05:47    [W:0.159 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site