[lkml]   [2000]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [RFC] Implementing temporal affinity

    > On Fri, 25 Aug 2000, Chris Swiedler wrote:
    > > > > B only ran for 15 cycles, and therefore it ISN'T the time-affinity
    > > > process.
    > > >
    > > > But it is. It's run long enough to load the CPU cache with it's own
    > > > instructions and data. Since you are trying to preserve the CPU cache,
    > > > you want it to run again instead of something else. Right?
    > >
    > > We would only set last_cpu IF the process has run for N cycles,
    > > where N is enough to fill the CPU cache. If 15 cycles loads the
    > > cache, then N=15. So in that case, B's last_cpu would be set,
    > > and it would be tied to that processor. The actual value is
    > > tunable, and depends largely on the size of the L2 cache.
    > That doesn't make much sense. If a process gave up the CPU
    > after very few cycles (because vi was ready echoing back
    > the key you typed), it has everything it needed to do that
    > in the cache...

    Is this true? I was under the impression that it took a certain number of
    cycles to fill up the CPU cache. If a process executes 1 instruction, is the
    cache going to be full of its data? How about 10, 20, 300? I was thinking
    that there was some number of cycles N, and processes which executed for
    less than N wouldn't have a signifigant amount of information in the cache.

    I'm reasonably certain that (even if it would work) the patch wouldn't be
    worth the extra instructions in schedule(), but that's a different story...


    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.023 / U:33.296 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site