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

Ingo Molnar
2007-03-01T08:53:57Z

* Mike Galbraith <efault@gmx.de> 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