* Mike Galbraith <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
