Re: SD_SHARE_CPUPOWER breaks scheduler fairness

[Steve Rotolo <steve.rotolo@ccur.com>]

On Tue, 2005-05-31 at 22:49, Con Kolivas wrote:
> Sort of yes and yes. The idea that the sibling gets put to sleep if a real 
> time task is running is a workaround for the fact that you do share cpu power 
> (as you've correctly understood) and a real time task will slow down if a 
> SCHED_NORMAL task is running on its sibling which it should not.  The 
> limitation is that, yes, for all intents you only have N hyperthreaded cpus 
> for spinning N rt tasks before nothing else runs, but you can actually run 
> N*2 rt tasks in this setting which you would not be able to if hyperthreading 
> was disabled.
> 
> For some time I've been thinking about changing the balance between the 
> siblings slightly to allow SCHED_NORMAL tasks to run a small proportion of 
> time when rt tasks are running on the sibling. The tricky part is that 
> SCHED_FIFO tasks have no timeslice so we can't proportion cpu out according 
> to the difference in size of the timeslices, which is currently how we 
> proportion out cpu across siblings with SCHED_NORMAL, and this maintains cpu 
> distribution very similarly to how 'nice' does on the same cpu.

Thanks for responding, Con.  But I want to make sure that an important
point doesn't escape your attention.  It appears that tasks get trapped
on the stalled sibling, even when they could run on some other cpu.  The
load-balancer does not understand that the sibling is temporarily out of
service so it actually balances tasks to it.  And since it's idle, it
may attract tasks to it more than other cpus (thanks to SD_WAKE_IDLE). 
I think this is a serious bug.

-- 
Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/