[lkml]   [2001]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][RFC] Proposal For A More Scalable Scheduler ...
On Tue, 30 Oct 2001, Hubertus Franke wrote:

> > Real time processes, when wakeup up fall calling reschedule_idle() that
> > will either find the CPU idle or will be reschedule due a favorable
> > preemption_goodness().
> > One of balancing scheme I'm using tries to distribute RT tasks evenly on
> > CPUs.
> >
> I think that would be a problem. My understanding is that if two RT process
> are globally runnable, then one must run the one with higher priority.
> Am I missing something here ?

The only difference is when an RT task is currently running and another RT
task kicks in with a not favorable preemption_goodness().
In the current scheduler reschedule_idle() loops through the CPUs to find
one for the incoming RT tasks while the proposed scheduler actually
What I'm coding is to plug in get_best_cpu() a way to evenly spread RT
tasks between CPUs.
But even the RT task rapid move to another CPU is not too rapid due
IPI+schedule() latency.
Maybe it's faster the currently running RT tasks to reschedule instead of
the remote CPU, maybe :)
The current IPI method creates very funny/undesirable behavior due
IPI+schedule() latency.
When watching at the schedcnt dump of a lat_ctx of my 2 way SMP
system, I saw both tasks lying on the same CPU with the other one
tempested by reschedule IPI without being able to catch one task due latency.

- Davide

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: 2005-03-22 13:12    [W:0.091 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site