1. Once a second rebalance() is called on cpu0 to adjust priorities,
so cpu-bound processes won't lock others out.  However it was only
adjusting processes which were running on cpu0.  This was observed
to lead to livelock, eg when a higher-priority process spin-waits
for a lock held by a lower priority one.

2. When mmu mapping for a shared segment is changed, procflushseg
is called to wait for other cpus to change their mapping.  The
loop contains a sched() call which could return on a different cpu,
and therefore cause some cpus in the list to be skipped