[lkml]   [2000]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.020 / U:13.008 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site