Re: Fix up riscom8 driver to use work queues instead of task queueing.

Jeff Garzik
2003-08-18T19:25:43Z

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
mitigated.

Jeff