Re: 2.4: why is NR_GFPINDEX so large?

[kanoj@google.engr.sgi.com (Kanoj Sarcar)]

> 
> ** Reply to message from Kanoj Sarcar <kanoj@google.engr.sgi.com> on Wed, 21
> Jun 2000 12:56:12 -0700 (PDT)
> 
> 
> > This is a left over from the days when we had a few more __GFP_ flags,
> > but that has been cleaned up now, so NR_GFPINDEX can go down. 
> 
> Cool.  I'm glad to see that my questions wasn't stupid :-)

Best way to verify this is change NR_GFPINDEX to whatever you think
is right, then see whether the resulting kernel comes up fine in
multiuser mode with networking and X.

> 
> >Be aware 
> > of any cache footprint issues though.
> 
> Ok, you just lost me.  What's a "cache footprint"?
>

Even though there is unused space, that might be padding out certain
data structures to cache line aligned sizes, causing lesser cache
line eviction etc, at the cost of few more bytes of unused space. On
certain applications, this can cause a noticeable improvement.

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