Re: scheduler interactivity: timeslice calculation seem wrong

[Andrew Theurer <habanero@us.ibm.com>]

On Tuesday 19 August 2003 23:11, Bill Davidsen wrote:
> On Tue, 19 Aug 2003, William Lee Irwin III wrote:
> > On Tue, Aug 19, 2003 at 05:32:04PM -0700, David Lang wrote:
> > > while thinking about scaling based on CPU speed remember systems with
> > > variable CPU clocks (or even just variable performance like the
> > > transmeta CPU's)
> >
> > This and/or mixed cpu speeds could make load balancing interesting on
> > SMP. I wonder who's tried. jejb?
>
> Hum, I *guess* that if you are using some "mean time between dispatches"
> to tune time slice you could apply a CPU speed correction, but mixed speed
> SMP is too corner a case for me. I think if you were tuning time slice by
> mean time between dispatches (or similar) you could either apply a
> correction, set affinity low to keep jobs changing CPUs, or just ignore
> it.

One could continue this thinking (more load_balance corrections than 
timeslice, IMO) on to SMT processors, where the throughput of a sibling is 
highly dependent on what the other siblings are doing in the same core.  For 
example, in a dual proc system, the first physical cpu with one task will run 
much faster than the second cpu with 2 tasks.  Actually, using a shared 
runqueue would probably fix this (something we still don't have in 2.6-test).

But one other thing, and maybe this has been brought up before (sorry, I have 
not been following all the discussions), but why are we not altering 
timeslice based on the runqueue length for that processor?  Would it not make 
sense, for the sake of good interactivity, to lower all the timeslices when 
we have a longer runqueue?

-Andrew Theurer