Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754209AbZGNJgU (ORCPT ); Tue, 14 Jul 2009 05:36:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753815AbZGNJgU (ORCPT ); Tue, 14 Jul 2009 05:36:20 -0400 Received: from ms01.sssup.it ([193.205.80.99]:49572 "EHLO sssup.it" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753619AbZGNJgT (ORCPT ); Tue, 14 Jul 2009 05:36:19 -0400 Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel From: Raistlin To: Peter Zijlstra Cc: Henrik Austad , LKML , Ingo Molnar , Bill Huey , Linux RT , Fabio Checconi , "James H. Anderson" , Thomas Gleixner , Douglas Niehaus , Ted Baker , Dhaval Giani In-Reply-To: <1247560935.7500.48.camel@twins> References: <200907102350.47124.henrik@austad.us> <1247336891.9978.32.camel@laptop> <1247478955.8107.24.camel@Palantir> <1247480080.7529.66.camel@twins> <1247501182.8107.572.camel@Palantir> <1247560935.7500.48.camel@twins> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UYxh8sgEJVKJL0aRDM2q" Date: Tue, 14 Jul 2009 11:36:12 +0200 Message-Id: <1247564172.9086.26.camel@Palantir> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1972 Lines: 55 --=-UYxh8sgEJVKJL0aRDM2q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-07-14 at 10:42 +0200, Peter Zijlstra wrote: > On Mon, 2009-07-13 at 18:06 +0200, Raistlin wrote: > > Anyway, maybe if, on some architecture, for some kind of application, > > the affinity may have been set to preserve some kind actual cache or > > memory locality for the task access pattern, maybe this could be an > > issue, couldn't it? :-) > > I mean, in some case where being sure of having a task running on a > > particular CPU is somehow of paramount importance... >=20 > Right, and you answered your own question :-), its _running_ that is > important, so as long as its blocked (not running), you're free to place > the task on another cpu if that helps out with something. >=20 Yep! Re-reading both your and my comments I saw I misunderstood your point! :-( I agree thet you have to move some task and, moving the "blocked" ones, would allow the lock-owner to continue running in its place, which sounds good to me to. :-) Sorry! 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 --=-UYxh8sgEJVKJL0aRDM2q 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) iEYEABECAAYFAkpcUYUACgkQk4XaBE3IOsS95wCeOGAiZRgfqY4RotkmSG1IA3UP ArsAnAjpf2rzuI3k6qWHOx8sY8VtA5t6 =GjuC -----END PGP SIGNATURE----- --=-UYxh8sgEJVKJL0aRDM2q-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/