linux-kernel - Re: [RFC][PATCH 20/22] sched: drafted deadline inheritance logic

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]

Date:	Sun, 14 Nov 2010 13:00:35 +0100
From:	Raistlin <raistlin@...ux.it>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Chris Friesen <cfriesen@...tel.com>, oleg@...hat.com,
	Frederic Weisbecker <fweisbec@...il.com>,
	Darren Hart <darren@...art.com>,
	Johan Eker <johan.eker@...csson.com>,
	"p.faure" <p.faure@...tech.ch>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Claudio Scordino <claudio@...dence.eu.com>,
	michael trimarchi <trimarchi@...is.sssup.it>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Juri Lelli <juri.lelli@...il.com>,
	Nicola Manica <nicola.manica@...i.unitn.it>,
	Luca Abeni <luca.abeni@...tn.it>,
	Dhaval Giani <dhaval@...is.sssup.it>,
	Harald Gustafsson <hgu1972@...il.com>,
	paulmck <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 20/22] sched: drafted deadline inheritance logic

On Thu, 2010-11-11 at 23:15 +0100, Peter Zijlstra wrote:
> > Acting this way, we provide some kind of boosting to the lock-owner,
> > still by using the existing (actually, slightly modified by the previous
> > commit) pi-architecture.
> 
> Right, so this is the trivial priority ceiling protocol extended to
> bandwidth inheritance and we basically let the owner overrun its runtime
> to release the shared resource.
> 
We can call it that way. Basically, what we do is scheduling the
lock-owner with the parameters, i.e., runtime and deadline, of the
earliest deadline task blocked on it. As soon as such runtime depletes,
we (1) _do_ postpone that deadline (again, according to earliest
deadline lock-owner's relative deadline), but we also (2) immediately
replenish the runtime _immediately_.

Acting like this we ensure the lock-owner won't hurt the guarantees
provided to tasks with deadline earlier than all the tasks in its
blocking chains (by means of (1)), and we also enable a quicker release
of the lock (by means of (2)).

> Didn't look at it too closely, but yeah, that is a sensible first
> approximation band-aid to keep stuff working.
> 
I'll keep going this way then. :-)

Thanks,
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" (199 bytes)