lkml.org 
[lkml]   [2000]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: [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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site