> B only ran for 15 cycles, and therefore it ISN'T the time-affinity process.
...
> I think a better way to do it would be to keep a per-CPU pointer to the last
> task to run. That way, no more than one process "owns" a CPU. If we keep it
...
around 2.3.30, there was code in the kernel to this effect.
the SMP boot code produced an estimate of how long (in cycles)
a cache-flush would cost. the scheduler kept a smoothed estimate
of how many cycles a task was expected to run, and which CPU
it last ran on. "frequent schedulers", which ran less than a
cache-flush period, were more likley to hop to other CPUs.
does anyone know why this code went away? were there indications
that it didn't work well, or did our Mighty Penguin simply decide
that it was unjustifiable fanciness? ;)
"A society that will trade a little fanciness for a little
performance will lose both, and deserve neither" - !Thomas Jefferson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:16 EST