Messages in this thread |  | | Date | Fri, 25 Aug 2000 15:48:46 -0400 (EDT) | From | Mark Hahn <> | Subject | RE: [RFC] Implementing temporal affinity |
| |
> 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/
|  |