linux-kernel - Re: [PATCH 03/19] scheduler: implement workqueue scheduler class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.01.0910011152080.6996@localhost.localdomain>
Date:	Thu, 1 Oct 2009 12:06:49 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Avi Kivity <avi@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Tejun Heo <tj@...nel.org>, jeff@...zik.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	jens.axboe@...cle.com, rusty@...tcorp.com.au,
	cl@...ux-foundation.org, dhowells@...hat.com, arjan@...ux.intel.com
Subject: Re: [PATCH 03/19] scheduler: implement workqueue scheduler class

On Thu, 1 Oct 2009, Ingo Molnar wrote:
>
> > So tying this to the scheduler class seems a bit odd. But maybe I'm 
> > missing something?
> 
> 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.

I don't think that works. I think the preempt notifiers are done too early 
and too late (ie they are done at the actual context switch), which what 
Tejun's code wants is to be called so that he can actually _do_ something 
about the task before the next task is selected.

But if the preempt-notification users are ok with being called earlier, 
then yes, I guess we could share the logic (and rename it). I do agree 
that what I'd like to see is more _like_ those preempt notifications, with 
a list of things to do before/after.

> They are per task - we would simply make preempt notifiers 
> unconditional, i.e. remove CONFIG_PREEMPT_NOTIFIERS and make it all 
> unconditional scheduler logic.

I don't mind that, but see above: I think the semantics are fundamentally 
different. One wants to be called exactly when the actual context switch 
happens, the other wants to be called before the choice of the next thread 
is even done (which in turn can mean that no context switch actually 
happens at all, because maybe you end up picking the same thread after 
all - possibly _due_ to the callback doing something)

But it's possible that I'm making a semantic difference out of something 
that nobody actually cares about.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/