CACHE_LINE_SIZE on x86

Jim Harris jim.harris at gmail.com
Thu Oct 25 21:40:15 UTC 2012


On Thu, Oct 25, 2012 at 2:32 PM, John Baldwin <jhb at freebsd.org> wrote:
> On Thursday, October 25, 2012 12:30:02 pm Andre Oppermann wrote:
>> On 25.10.2012 15:18, John Baldwin wrote:
>> > On Wednesday, October 24, 2012 3:13:38 pm Jim Harris wrote:
>> >> While investigating padding of the ULE scheduler locks (r242014), I
>> >> recently discovered that CACHE_LINE_SIZE on x86 is defined as 128 (not
>> >> 64).  From what I can tell from svn logs, this was to account for 128
>> >> byte cache "sectors" that existed on the NetBurst micro architecture
>> >> CPUs.
>> >>
>> >> I'm curious if there's been consideration in changing this back to 64?
>> >>   With maybe a kernel config option to modify it?  On 2S systems (but
>> >> not on 1S systems), I see a benefit using CACHE_LINE_SIZE=128 for the
>> >> scheduler locks.  I suspect this is related to data prefetching but am
>> >> still running experiments to verify.
>> >
>> > All the i7 and later systems I've seen (maybe even Penryn?) have a BIOS option
>> > (typically enabled by default) to enable adjacent cache line prefetching (my
>> > understanding is that this only affects the LLC, and it seems to always fetch
>> > an aligned 128 bytes, so if your miss is in the "second" line it fetches N-1
>> > and N, not always fetching N and N+1).  That is why I thought we still use 128
>> > bytes on x86.
>>
>> As long as the additionally prefetched cache line has its own MOESI
>> state and gets marked as shared there is not problem with using only
>> 64B alignment and padding.
>
> It would be good to know though if there are performance benefits from
> avoiding sharing across paired lines in this manner.  Even if it has
> its own MOESI state, there might still be negative effects from sharing
> the pair.

On 2S, I do see further benefits by using 128 byte padding instead of
64.  On 1S, I see no difference.  I've been meaning to turn off
prefetching on my system to see if it has any effect in the 2S case -
I can give that a shot tomorrow.

> --
> John Baldwin


More information about the freebsd-arch mailing list