Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH 1/2] kthread_create | Date | Fri, 02 Jan 2004 10:51:07 +1100 |
| |
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/
| |