Message-ID: <4AC5F0AD.2080904@kernel.org>
Date: Fri, 02 Oct 2009 21:23:09 +0900
From: Tejun Heo <tj@kernel.org>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
CC: jeff@garzik.org, mingo@elte.hu, linux-kernel@vger.kernel.org,
       akpm@linux-foundation.org, jens.axboe@oracle.com, rusty@rustcorp.com.au,
       cl@linux-foundation.org, dhowells@redhat.com, arjan@linux.intel.com
Subject: Re: [PATCH 03/19] scheduler: implement workqueue scheduler class
References: <1254384558-1018-1-git-send-email-tj@kernel.org> <1254384558-1018-4-git-send-email-tj@kernel.org> <alpine.LFD.2.01.0910010953010.6996@localhost.localdomain>
In-Reply-To: <alpine.LFD.2.01.0910010953010.6996@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1844
Lines: 46

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