Re: 2.4: why is NR_GFPINDEX so large?

[James Manning <jmm@computer.org>]

[Timur Tabi]
> ** Reply to message from Kanoj Sarcar <kanoj@google.engr.sgi.com> on Wed, 21
> Jun 2000 13:49:56 -0700 (PDT)
> > What I was warning you about is that if you shrink the array to the
> > exact size, there might be other data that comes on the same cacheline,
> > which might cause all kinds of interesting behavior (I think they call
> > this false cache sharing or some such thing).
> 
> Ok, I understand your explanation, but I have a hard time seeing how false
> cache sharing can be a bad thing.
> 
> If the cache sucks up a bunch of zeros that are never used, that's definitely
> wasted cache space.  How can that be any better than sucking up some real data
> that can be used?

The (possible) problem is that by decreasing the size of the array,
you're shifting data structures in memory and therefore shifting
their placement in caches.  Since caches exist as sets of cache lines
(an N-way associative cache having N members of each of these sets),
we may have shifted some high-traffic cachelines into the same set as
this structure.  We also may have made the situation better, but it's
hard to tell without real data on cache behavior (something I'm working
on now, but it's going slowly).

Of course, since gcc is the blessed compiler we can specify alignments
of structures to try and help the situation, and page coloring may
help the situation later down the road as well.

James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/