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

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.031 / U:11.876 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site