Re: [PATCH 1/2] kthread_create

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2003-12-31 at 17:34, Jeff Garzik wrote:
> Rusty Russell wrote:
> > For #2, if you really can't wait for keventd, perhaps your own
> > workqueue is in order?
> 
> Way too wasteful, and doing so is working around a fundamental failing 
> of workqueues:  keventd gives no guarantee that your scheduled work will 
> be executed this week, this month, or this year :)
> 
> keventd is used by two competing classes of users:  those who want 
> low-latency, quick execution in task context (Tux-ish), and those who 
> just want to run something in task context, where they might sleep 
> (perhaps for a long time).

That why those ones could be replaced by short-lived threads... I use
a short lived thread for ADB probing and I'm considering doing so for
things like ethernet NIC reset etc... which is definitely scheduling
way too long in keventd

> So it would be nice to have thread pool semantics occasionally found in 
> userspace:  if thread pool is full when new work is queued, 
> _temporarily_ increase the pool size (or create a one-shot kthread). 
> Sure you have kthread creation overhead, but at least you have a 
> reasonable guarantee that your work won't wait 5-30 seconds or more 
> before being performed.

The overhead isn't big (and even lower with kthread I suppose due to
not doing daemonize() & reparent_to_init()) so for occasional
long-sleeping crap, short lived kthreads seem to be the solution. If
those end up not using keventd any more (except for actual creation
of the short lived thread), there is probably no need for a thread pool
thing, only low latency stuffs will still use work_queue.

Ben.