> 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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:21 EST