> I changed reschedule idle this way:
[snip sane stuff]
> o If none CPU is grabbing the big kernel lock then
> o if the avg_slice of the new task is very short
> and the new task is not returning from fork then
> try to reschedule only over the preferred CPU.
Hmmm. Let's see what the consequences of this decision will be:
- new tasks are placed on an idle CPU, this is always good
(now that I think of it, new tasks are always penalized
in goodness() -- should we consider this harmful?)
- short-slice tasks might have to wait for long-slice tasks
(if the priority of the long-slice task is higher)
- while waiting, another short-slice task (on another CPU)
might have chosen to reschedule, hence freeing up it's
CPU and giving it to our waiting task
- this might cause some 'grouping' of short-slice and long-slice
tasks on each CPU -- this increases throughput for long-slice
tasks, decreases latency for short-slice tasks and might even
reduce memory contention between processors
This last effect, however much we might want it (do we?), is
very much implicit and not 'formalized' in code.
If we really want to have this effect, do we want to put it
into code or at least document it?
> The current way to use the related in reschedule_idle_slow seems
> just a random way to use related().
Agree. The current way is almost completely bogus, especially
on quad (or more) CPU machines...
[snip SCHED_YIELD patch that absolutely _has_ to go into
the next official kernel]
cheers,
Rik -- Open Source: you deserve to be in control of your data.
+-------------------------------------------------------------------+
| Le Reseau netwerksystemen BV: http://www.reseau.nl/ |
| Linux Memory Management site: http://www.linux.eu.org/Linux-MM/ |
| Nederlandse Linux documentatie: http://www.nl.linux.org/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/