Did you try to cook beef skewers on a BBQ ? A BBQ is not a balanced heat source, and skewers are difficult to turn around. The result is that some pieces are burned while others are still raw.
For sure OS makers are aware of this problem. The proof ? Try to run an infinite loop in a shell, like in bash: while true; do
The naive answer suggests one core is 100% busy while others are free. However the reality is different. On XP, the OS scheduler happily migrates the infinite loop process from one core to another making all cores partially busy with this infinite process.
Advantages: the only one I see is that load balancing avoids extra heat on one part of the CPU, exactly as if the skewer where regularly turned and moved around all over the grid to be better cooked.
Drawback: the process migrates, which means in addition to context switch overhead the data are copied from one L2 cache to another. Overall time is longer than on a mono-core machine.
Workaround: You can pinpoint a thread on one core and prevent it to migrate elsewhere. This is called "single core affinity".
1 comment:
Just to be more precise: the load balancing is probably a side effect. During a context switch, the next process is loaded into the current core. Since nothing special is done by default to stick a process to a core, the process is restored randomly in the next available core.
Also, this is true for other SMP (symmetrical multi processors) OS than XP...
Post a Comment