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: <1247786951.4929.52.camel@Palantir>
Date:	Fri, 17 Jul 2009 01:29:11 +0200
From:	Raistlin <raistlin@...ux.it>
To:	Ted Baker <baker@...fsu.edu>
Cc:	"James H. Anderson" <anderson@...unc.edu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Chris Friesen <cfriesen@...tel.com>,
	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>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Noah Watkins <jayhawk@....ucsc.edu>,
	KUSP Google Group <kusp@...glegroups.com>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Giuseppe Lipari <lipari@...is.sssup.it>,
	Bjoern Brandenburg <bbb@...unc.edu>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel

On Wed, 2009-07-15 at 16:55 -0400, Ted Baker wrote:
> I hope that Linux will not pursue EDF or EDZL in only a narrow
> sense, as simple priority scheduling algorithms, without providing
> for bandwidth guaranteees and limits.
> 
Yes, me to...

> By bandwith "guarantee" I mean that the task/scheduling entity is
> guaranteed to be able to at least *compete* at a certain level for
> a certain percentage of the CPU, if we cannot (better) provide an
> admission control mechanism that guarantees it will actually get a
> certain percentage of the CPU.
>
Again, I agree... But giving a group an explicit priority assignment,
although very simple conceptually, raises a lot of issues when the
current implementation of global task scheduling in Linux, with
"distributed" (one per CPU) runqueue, is concerned.

> For example, in the fixed-priority domain, we have Sporadic
> Server.  This guarantees the server a chance to compete at its top
> priority for at least sched_ss_init_budget time in every
> sched_ss_repl_period time, at sched_priority, within some
> tolerance.  It also should not be permitted to use more than
> sched_ss_init_budget time in every sched_ss_repl_period time, at
> sched_priority, within some tolerance.
> 
And that's why I'm trying what I said before... For, e.g., the sporadic
server policy to extend and be applied to group scheduling, groups need
to have priorities for the standard, already existent, analysis to work.

> In the deadline scheduling domain, we have algorithms like
> Constant Bandwidth Server (and some improved variants) that
> provide similar gurantees and limites, in terms of deadlines.  (I
> recall seeing one very good version in a paper I recently saw,
> which I could seek out and provide to the list if there is
> interest.)
> 
Well, if it does not bother you too much, I'm curious about that
solution... When you find some time, even via private mail, if I'm the
only one, it would be nice if you can point that paper out to me.

Thanks in advice.

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)