[lkml]   [2006]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RT task scheduling
On Fri, Apr 07, 2006 at 09:11:25AM +0200, Ingo Molnar wrote:
> * Bill Huey <> wrote:
> > On Thu, Apr 06, 2006 at 09:37:53AM +0200, Ingo Molnar wrote:
> > > do "global" decisions for what RT tasks to run on which CPU. To put even
> > > less overhead on the mainstream kernel, i plan to introduce a new
> > > SCHED_FIFO_GLOBAL scheduling policy to trigger this behavior. [it doesnt
> > > make much sense to extend SCHED_RR in that direction.]
> >
> > You should consider for a moment to allow for the binding of a thread
> > to a CPU to determine the behavior of a SCHED_FIFO class task instead
> > of creating a new run category. [...]
> That is already possible and has been possible for years.

I know that this is already the case. What I'm saying is that the creation
of new globally scheduled run case isn't necessarly if you have a robust
thread to CPU binding mechanism, the key here is "robust". I'm suggesting
that you and the gang think in terms of that, in a first-class manner, for
app development instead of creating a new run category that would be almost
certainly abused by naive developers. IMO, the discussion should be about
that as well as setting aside a CPU for a dedicated task, popularly termed
"CPU isolations", that excludes any other task from running on it. This
something that was used fairly heavily under IRIX and is highly useful in
RT development.

The RT rebalancing discussion should be oriented toward manual techniques
for dealing with this on an app basis and not automatic load balancing
stuff or anything like that. IMO, going down this direction is basically
trying to solve a problem with the wrong tool set.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-04-07 10:44    [W:0.061 / U:10.760 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site