From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel Date: Tue, 14 Jul 2009 10:42:15 +0200 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Henrik Austad , LKML , Ingo Molnar , Bill Huey , Linux RT , Fabio Checconi , "James H. Anderson" , Thomas Gleixner , Douglas Niehaus , Ted Baker , Dhaval Giani To: Raistlin Return-path: Received: from viefep14-int.chello.at ([62.179.121.34]:19277 "EHLO viefep14-int.chello.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750820AbZGNImU (ORCPT ); Tue, 14 Jul 2009 04:42:20 -0400 In-Reply-To: <1247501182.8107.572.camel@Palantir> Sender: linux-rt-users-owner@vger.kernel.org List-ID: 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... 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.