From mboxrd@z Thu Jan 1 00:00:00 1970 From: Raistlin Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel Date: Fri, 17 Jul 2009 01:29:11 +0200 Message-ID: <1247786951.4929.52.camel@Palantir> References: <1247336891.9978.32.camel@laptop> <4A594D2D.3080101@ittc.ku.edu> <1247412708.6704.105.camel@laptop> <1247499843.8107.548.camel@Palantir> <4A5B61DF.8090101@nortel.com> <1247568455.9086.115.camel@Palantir> <4A5C9ABA.9070909@nortel.com> <1247589099.7500.191.camel@twins> <20090715205503.GA14993@cs.fsu.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-iixmZwmzoqEb8NdtUbUW" Cc: "James H. Anderson" , Peter Zijlstra , Chris Friesen , Douglas Niehaus , Henrik Austad , LKML , Ingo Molnar , Bill Huey , Linux RT , Fabio Checconi , Thomas Gleixner , Dhaval Giani , Noah Watkins , KUSP Google Group , Tommaso Cucinotta , Giuseppe Lipari , Bjoern Brandenburg To: Ted Baker Return-path: Received: from ms01.sssup.it ([193.205.80.99]:44130 "EHLO sssup.it" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933582AbZGPX3P (ORCPT ); Thu, 16 Jul 2009 19:29:15 -0400 In-Reply-To: <20090715205503.GA14993@cs.fsu.edu> Sender: linux-rt-users-owner@vger.kernel.org List-ID: --=-iixmZwmzoqEb8NdtUbUW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. >=20 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. >=20 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.) >=20 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 --=20 <> (Raistlin Majere) ---------------------------------------------------------------------- Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy) http://blog.linux.it/raistlin / raistlin@ekiga.net / dario.faggioli@jabber.org --=-iixmZwmzoqEb8NdtUbUW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpft8AACgkQk4XaBE3IOsRXKgCfWxk+FvELsneO/20uoyxcqGK4 KrEAoKr5NV5KJNJYRUsgek1kUscg/apE =bpkS -----END PGP SIGNATURE----- --=-iixmZwmzoqEb8NdtUbUW--