[lkml]   [2009]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.

 \ /
  Last update: 2009-10-01 21:05    [W:0.077 / U:0.768 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site