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

> 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...

chris

-
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