> > > 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?
>
> No, but if the process sleeps voluntarily after N cycles,
> you can be sure that the process has all the data it needed
> in that CPU's cache...
Ah, I see what you're getting at. OK, then, in the case of voluntary sleeps,
we set the last_cpu regardless of cycles used. I'm not sure if we can do
this automatically: I don't think we can distinguish voluntary from
involuntary in schedule(), and I don't know what functions are called when a
process sleeps. If not automatically, then maybe we can let kernelspace code
set the last_cpu manually, when it sleeps and wants the rescheduling
advantage.
> > 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...
>
> I'm absolutely sure that they are. With memory bandwidth
> being a real bottleneck and memory latencies being high,
> it should be worth it to make the scheduler take some
> cycles extra if we can make the L2 cache hit ratio higher
> by a few percent.
Well, then, I'll look into actually coding the patch.
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