Re: 2.4: why is NR_GFPINDEX so large?

[Timur Tabi <ttabi@interactivesi.com>]

** Reply to message from Kanoj Sarcar <kanoj@google.engr.sgi.com> on Wed, 21
Jun 2000 14:10:17 -0700 (PDT)


> Okay, I will shut up since I will have to pull out old notes and books
> to convince you, but basically, here's a simple example. Say a L2 cache 
> line is 128 bytes, and each array element is 16 bytes, giving 8 array 
> elements per cache line. Say you decide to eliminate the last element,
> maybe because it is not used. So, in that space, two global integers/
> spinlocks etc are packed in after the deletion. Further assume these
> two integers are frequently updated. Looking at an SMP system that uses
> the exlusive write cache update protocol, the cache line will probably
> bounce between the different L2 caches, which is quite bad, assuming 
> that the original 8 element array was readonly, and was probably 
> coresident in all the caches.

Fascinating.  I really appreciate your taking the time to explain this to me.  

So I suppose the best way to optimize this is to make sure that "NR_GFPINDEX *
sizeof(zonelist_t)" is a multiple of the cache line size?



--
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message.
--
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/