linux-kernel - Re: [RFC][PATCH] SCHED

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:	Wed, 23 Sep 2009 16:45:15 +0200
From:	Raistlin <raistlin@...ux.it>
To:	Linus Walleij <linus.ml.walleij@...il.com>
Cc:	Claudio Scordino <claudio@...dence.eu.com>,
	Peter Zijlstra <peterz@...radead.org>, michael@...dence.eu.com,
	mingo@...e.hu, linux-kernel@...r.kernel.org, tglx@...utronix.de,
	johan.eker@...csson.com, p.faure@...tech.ch,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Tommaso Cucinotta <tommaso.cucinotta@...up.it>
Subject: Re: [RFC][PATCH] SCHED_EDF scheduling class

On Wed, 2009-09-23 at 16:08 +0200, Linus Walleij wrote:
> > With EDF, instead, the test is much easier: if the bandwidth is less than
> > 100%, then you are sure that the deadlines will be met. In other words, you
> > can fully exploit processor bandwidth up to 100% being sure that timing
> > constraints of EDF tasks will be guaranteed.
> 
> This must be under the assumption that all code running in the system
> is preemtible, is it not? Which means, negligible or close to negligible
> non-preemptible code.
> 
Right. Moreover, this also happen only if tasks are independent, do not
share resources, etc. which all are things that do not apply to Linux...
This is more than true!

However, this holds for any scheduler you may decide to consider,
especially if a real-time one.
A scheduling test is always based on a task model and, at least, with a
simple --completely preemptible, independent tasks-- model, EDF is
simpler than other solutions.

Obviously, if the model gets more complicated, more complicated analysis
has to be used, and again, this happen to all the schedulers you will
try to analyze.

> How much as we might like it to be, that is not (yet) the situation
> with the Linux kernel, far off.
> 
> So we will still very much need the CONFIG_PREEMPT_RT patch
> to get closer to that ideal situation, and we still need to get rid of
> the BKL.
> 
Independently from the above, I agree with you here, and in fact a
SCHED_EDF patch on top of PREEMPT_RT will hopefully come shortly, we and
some other guys are already at work on this! ;-P

> Now I ought to write fewer mails and look into solving that little
> problem... You don't happen to know if we can have a EU FP7
> project sponsored to rid out the BKL and switch and test drivers
> en masse to use threaded interrupt handlers do you? ;-)
> 
Well, it's an interesting (applied) research topic, and I think there
still is a call for FP7 EU fundings! :-)

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)