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

[Jeff Garzik]

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



-
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/