linux-kernel - Re: RFC for a new Scheduling policy/class in the Linux-kernel

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1247746671.5775.279.camel@Palantir>
Date:	Thu, 16 Jul 2009 14:17:51 +0200
From:	Raistlin <raistlin@...ux.it>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ted Baker <baker@...fsu.edu>, Chris Friesen <cfriesen@...tel.com>,
	Noah Watkins <jayhawk@....ucsc.edu>,
	Douglas Niehaus <niehaus@...c.ku.edu>,
	Henrik Austad <henrik@...tad.us>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Bill Huey <billh@...ppy.monkey.org>,
	Linux RT <linux-rt-users@...r.kernel.org>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	"James H. Anderson" <anderson@...unc.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dhaval Giani <dhaval.giani@...il.com>,
	KUSP Google Group <kusp@...glegroups.com>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Giuseppe Lipari <lipari@...is.sssup.it>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel

On Thu, 2009-07-16 at 09:58 +0200, Peter Zijlstra wrote: 
> > Again, I don't think that either PP or PI is appropriate for use
> > in a (SMP) kernel. For non-blocking locks, the current
> > no-preeemption spinlock mechanism works.  For higher-level
> > (blocking) locks, I'm attracted to Jim Anderson's model of
> > non-preemptable critical sections, combined with FIFO queue
> > service.
> 
But, if I remember well how FMLP works, there is not that much
difference between them two... I mean, if you, at any (kernel|user)
level define a short critical section, this is protected by a
non-preemptive FIFO "queue lock", which is how Linux implements --at
least on x86-- spinlocks! :-O

Also, I'm not sure I can find in the FMLP paper information about the
possibility of a task to suspend itself (e.g., I/O completion) while
holding a short lock... I assume this is not recommended, but may be
wrong, and, in that case, I hope Prof. Anderson and Bjorn will excuse
and correct me. :-)

On the other hand, if with "blocking locks" you intended the long ones,
I think they hare dealt right with suspension and priority inheritance,
even in there.

> Right, so there's two points here I think:
> 
>  A) making most locks preemptible
>  B) adding PI to all preemptible locks
> 
> I think that we can all agree that if you do A, B makes heaps of sense,
> right?
> 
I don't know about all, but I do... I hope I'm not offending anyone
saying that I like priority inheritance!! :-P

> Of course, when the decreased period is still sufficient for the
> application at hand, the non-preemptible case allows for better
> analysis.
> 
Sure! I am impressed as well by the amazing results approaches like the
FMLP give in term of schedulabiulity analysis, and think a little bit of
spinning would not hurt that much, but not to the point of moving all
the locking to spinlocks. :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@...ga.net /
dario.faggioli@...ber.org

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)