[lkml]   [2003]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Fix up riscom8 driver to use work queues instead of task queueing.
On Mon, Aug 18, 2003 at 12:12:19PM -0700, Linus Torvalds wrote:
> On Mon, 18 Aug 2003, Jeff Garzik wrote:
> >
> > schedule_work() is _not_ for that. As currently implemented, you have
> > no guarantees that your schedule_work()-initiated work will even
> > begin in this century.
> In theory yes. In practice no. schedule_work() tries to wake up the worker
> process immediately, and as such usually gets the work done asap.
> But hey, if you want to improve on the drivers, please go wild. I care
> more about "real life working" than "theoretical but doesn't work".

hehe ;-) well,

* I've hit this situation in real life (waiting on a driver doing
error handling, hogging the single shared workqueue on UP). It
actually gets nasty if a bunch of drivers all throw errors at
the same time... (more below)

* re "improve the drivers" -- if you mean "fixing" those hogging the
shared workqueue, I think that's a workqueue API flaw. If you mean
further fix up the drivers you just modified, well... I think
slackness on my part will win there :)

There was talk in another thread about fixing up workqueue to create
a new kernel thread, if one isn't available within five seconds.
That seemed reasonable to me. Another useful addition to workqueue,
for drivers, would be a one-shot thread "runme(func, func_data)" API.
I think a lot of the device driver error handling is more appropriate
to this one-shot API than the current workqueue API. Error handling is
already a slow path, so the overhead of thread creation on each call is


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.067 / U:2.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site