On Mon, 28 Aug 2000, Chris Swiedler wrote:
> > On Fri, 25 Aug 2000, Chris Swiedler wrote:
> >
> > > 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?
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...
> 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.
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
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