shrink per_cpu_pages to fit 32byte cacheline]
PATCH 1/1 shrink per_cpu_pages to fit 32byte cacheline]
Forgot to CC linux-kernel, just in case someone else can have useful information on this matter.
Andi says any additional overhead will be in the noise compared to cacheline saving benefit.
***********
Jun,
We need some assistance here - you can probably help us.
Within the Linux kernel we can benefit from changing some fields of commonly accessed data structures to 16 bit instead of 32 bits, given that the values for these fields never reach 2 ^ 16.
Arjan warned me, however, that the prefix (in this case "data16") will cause an additional extra cycle in instruction decoding, per message above.
Can you confirm that please? We can't seem to be able to find it in Intel's documentation.
By shrinking two fields of "per_cpu_pages" structure we can fit it in one 32-byte cacheline (<= Pentium III and probably several other embedded/whatnot architectures will benefit from such a change).
And we just shrank two fields of "struct pagevec" in a similar way in Andrew's -mm tree.
I'm adding linux-kernel just in case someone else can have useful comments.
Thanks.
----- Forwarded message from Arjan van de Ven <[email protected]> -----
From: Arjan van de Ven <[email protected]>
Date: Tue, 14 Sep 2004 13:13:29 +0200
To: Marcelo Tosatti <[email protected]>
Cc: [email protected], "Martin J. Bligh" <[email protected]>,
[email protected]
In-Reply-To: <[email protected]>
Subject: Re: [PATCH] shrink per_cpu_pages to fit 32byte cacheline
Original-Recipient: rfc822;[email protected]
X-Loop: [email protected]
X-MIMETrack: Itemize by SMTP Server on USMail/Cyclades(Release 6.5.1|January 21, 2004) at
09/14/2004 03:13:02
Quoted 1 line · Marcelo Tosatti
How come short access can cost 1 extra cycle? Because you need two "read bytes" ?
on an x86, a word (2byte) access will cause a prefix byte to the instruction, that particular prefix byte will take an extra cycle during execution of the instruction and potentially reduces the parallal decodability of instructions....
----- End forwarded message -----
----- End forwarded message -----
Quoted 15 lines · Marcelo Tosatti
Forgot to CC linux-kernel, just in case someone else can have useful information on this matter.
Andi says any additional overhead will be in the noise compared to cacheline saving benefit.
***********
Within the Linux kernel we can benefit from changing some fields of commonly accessed data structures to 16 bit instead of 32 bits, given that the values for these fields never reach 2 ^ 16.
Arjan warned me, however, that the prefix (in this case "data16") will cause an additional extra cycle in instruction decoding, per message above.
Quoted 6 lines
Can you confirm that please? We can't seem to be able to find it in Intel's documentation.
By shrinking two fields of "
per_cpu_pages" structure we can fit it in one 32-byte cacheline (<= Pentium III and probably several other embedded/whatnot architectures will benefit from such a change).
One cycle is a small overhead compared to the cost of a fetch from L2 cache or, even worse, a cache miss. Memory is terribly slow. I think that nowadays we should design things trying to keep memory accesses as few as possible.
--
Giuliano.