mirror of
git://git.9front.org/plan9front/plan9front
synced 2025-01-12 11:10:06 +00:00
[Mirror] Some kind of OS: git://git.9front.org/plan9front/plan9front
3598b7cf36
On a multiprocessor, the scheduler can run into a very unfair distribution of processes to cpus when there are more long-running processes than cpus. Say we have a 4 cpu machine and we run 4 long-running proesses, each cpu will pick up a single process and each process will get 100% of its fair share. Everything is good so far. If we start more long-running processes, all these processes are going to be picked up by the cpu core that runs most sporanic / bursty work loads as it is calling sched() more often. This results in all the extra long-running prcoesses to cluster around the same core resulting in very unfair sharing of load. The problem is that once a process runs on a cpu, it stays on that cpu as processor affinity is never reset. Process migration only happens when a cpu cannot find any process to run, given the affinity constrains, but this can never happen when the system is under full load and each cpu always has a low-priority long running process to run. How do we fix this? The idea of this hack is to reset processor affinity in ready() when its priority changes or, when it appears to be a long-running process. That way, we give every cpu a chance to pick it up and share the load. This is not a ideal solution of course. Long term, we should probably have separate runqueues per cpu and do the balancing explicitely. |
||
|---|---|---|
| 386 | ||
| 68000 | ||
| 68020 | ||
| acme | ||
| adm/timezone | ||
| amd64 | ||
| arm | ||
| arm64 | ||
| lib | ||
| mips | ||
| power | ||
| power64 | ||
| rc | ||
| sparc | ||
| sparc64 | ||
| spim | ||
| sys | ||