Messages in this thread | | | Date | Thu, 01 Oct 2009 21:00:23 +0200 | From | Avi Kivity <> | Subject | Re: [PATCH 03/19] scheduler: implement workqueue scheduler class |
| |
On 10/01/2009 08:48 PM, Ingo Molnar wrote: > We could do what Avi suggested: not use scheduler classes at all for > this (that brings in other limitations like lack of p->policy freedom), > but use the existing preempt-notifications callbacks. > > They are per task - we would simply make preempt notifiers > unconditional, i.e. remove CONFIG_PREEMPT_NOTIFIERS and make it all > unconditional scheduler logic. > >
Sure, but it would mean that we need a new notifier. sched_out, sched_in, and wakeup (and, return to userspace, with the new notifier).
btw, I've been thinking we should extend concurrency managed workqueues to userspace. Right now userspace can spawn a massive amount of threads, hoping to hide any waiting by making more work available to the scheduler. That has the drawback of increasing latency due to involuntary preemption. Or userspace can use one thread per cpu, hope it's the only application on the machine, and go all-aio.
But what if we added a way for userspace to tell the kernel to fork off threads when processing power and work to do are both available? The scheduler knows when there is processing power, and an epoll fd can tell it when there is work to do. So the scheduler will create threads to saturate the processors, if one of them waits for I/O the scheduler forks off another one until all queues are busy again.
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
| |