Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Ingo Molnar]

* Mike Galbraith <efault@xxxxxx> wrote:

> I see no real difference between the two assertions.  Nice is just a 
> mechanism to set priority, so I applied your assertion to a different 
> range of priorities than nice covers, and returned it to show that the 
> code contradicts itself.  It can't be bad for a nice 1 task to run 
> with a nice 0 task, but OK for a minimum RT task to run with a maximum 
> RT task.  Iff HT without corrective measures breaks nice, then it 
> breaks realtime priorities as well.

i'm starting to lean towards your view that we should not artificially 
keep tasks from running, when there's a free CPU available. We should 
still keep the 'other half' of SMT scheduling: the immediate pushing of 
tasks to a related core, but this bit of 'do not run tasks on this CPU' 
dependent-sleeper logic is i think a bit fragile. Plus these days SMT 
siblings do not tend to influence each other in such a negative way as 
older P4 ones where a HT sibling would slow down the other sibling 
significantly.

plus with an increasing number of siblings (which seems like an 
inevitable thing on the hardware side), the dependent-sleeper logic 
becomes less and less scalable. We'd have to cross-check every other 
'related' CPU's current priority to decide what to run.

if then there should be a mechanism /in the hardware/ to set the 
priority of a CPU - and then the hardware could decide how to prioritize 
between siblings. Doing this in software is really hard.

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