lkml.org 
[lkml]   [2004]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/2] kthread_create
Date
In message <3FF26DFF.3040909@pobox.com> you write:
> Rusty Russell wrote:
> > For #2, if you really can't wait for keventd, perhaps your own
> > workqueue is in order?
>
> Way too wasteful,

I feel the same, which is one reason I didn't use them here...

> 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 :)

Hmm, I think that if you had an all-dancing, self-balancing workqueue
mechanism, you wouldn't need to create your own workqueues anyway.

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

If we're wishlisting, I'd prefer something which also scaled down
below one thread per cpu until required. Mainly because it just feels
wrong to have those threads sitting around doing mainly nothing.

Simple matter of coding, right?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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