Re: [patch] HT scheduler, sched-2.5.68-B2

[Martin J. Bligh]

>>> >  - turn off the more agressive idle-steal variant. This could fix the
>>> >    low-load regression reported by Martin J. Bligh.
>>> 
>>> Yup, that fixed it (I tested just your first version with just that
>>> bit altered).
>> 
>> Can we make this an arch specific option?  I have a feeling the HT performance 
>> on low loads will actually drop with this disabled.  

Actually, what must be happening here is that we're agressively stealing
things on non-HT machines ... we should be able to easily prevent that.

Suppose we have 2 real cpus + HT ... A,B,C,D are the cpus, where A, B 
are HT twins, and C,D are HT twins. A&B share runqueue X, and C&D share
runqueue Y

What I presume you're trying to do is when A and B are running 1 task
each, and C and D are not running anything, balance out so we have
one on A and one on C. If we define some "nr_active(rq)" concept to be
the number of tasks actually actively running on cpus, then if we we're
switching from nr_actives of 2/0 to 1/0.

However, we don't want to switch from 2/1 to 1/2 ... that's pointless.
Or 0/1 to 1/0 (which I think it's what's happening). But in the case
where we had (theoretically) 4 HT siblings per real cpu, we would want
to migrate 1/3 to 2/2.

The key is that we want to agressively steal when 
nr_active(remote) - nr_active(idle) > 1 ... not > 0.
This will implicitly *never* happen on non HT machines, so it seems
like a nice algorithm ... ?

M.