lkml.org 
[lkml]   [2009]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 03/19] scheduler: implement workqueue scheduler class
Hello, Linus.

Linus Torvalds wrote:
> On Thu, 1 Oct 2009, Tejun Heo wrote:
>> Implement workqueue scheduler class. Workqueue sched_class inherits
>> fair sched_class and behaves exactly the same as sched_class except
>> that it has two callback functions which get called when a task is put
>> to sleep and wakes up and doesn't allow switching to different
>> scheduler class.
>
> So this looks odd to me.
>
> I agree completely with the callback functions, but what I don't agree
> with is that this is somehow workqueue-related. I bet that others could
> use this, and in fact, I suspect that it should not be tied to the
> scheduler class at all, but to the _thread_.
>
> Just as an example, I could imagine that we would do lock_kernel()
> releasing the kernel lock on scheduling (and re-taking it on wakeup) as a
> callback. Or async IO handling - both done independently of any
> "workqueue" logic.
>
> So tying this to the scheduler class seems a bit odd. But maybe I'm
> missing something?

The only reason why the callbacks are implemented by inheriting
sched_class is because I thought it was a pretty special case, so
slightly lax on the hackish side while staying spartan on adding
hotpath overhead. If this type of notification mechanism is something
which can be used more widely, it would definitely be better to have
proper per-task callback mechanism instead. Probably per-task chain
of notifier ops so that only tasks which would be interested in such
events can opt in.

Avi, such per-task notification ops should be useable for kvm too,
right?

Thanks.

--
tejun


\
 
 \ /
  Last update: 2009-10-02 14:25    [W:0.103 / U:1.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site