Number (2) can be tackled with a number of scheduler adjustments:
- longer time slices (for CPU-bound tasks only!)
- make it harder to switch CPUs (depending on how long a process
has slept)
- more intelligent rescheduling in reschedule_idle() -- better
burn a few hundred cycles there than completely mess up the
cache of three CPUs and hogging the memory bus
- in tune with this, move the bottleneck in other pieces of
code from memory to CPU, better cache alignment of task
struct and stuff
If you have 8 CPUs, 8 CPU-bound tasks and one process
taking 10% of one CPU, it might just be better to have
one of the large tasks get 90% and the rest 100%.
Switching around the one non-hog might create such an
amount of cache/memory problems that it will make the
CPU hog suffer more than the 10% in question.
Weird counterintuitive things like this are what make
the difference between a high-performance OS and your
usual Redmond crap...
cheers,
Rik -- who prefers a certain OS with fairly non-intuitive innards.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
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/