Re: 2.4: why is NR_GFPINDEX so large?

Timur Tabi
2000-06-21T21:28:43Z

** 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.