Messages in this thread |  | | From | "Chris Swiedler" <> | Subject | RE: [RFC] Implementing temporal affinity | Date | Mon, 28 Aug 2000 12:14:01 -0400 |
| |
> > > 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/
|  |