Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Oct 2012 09:18:00 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-arch@freebsd.org
Cc:        Jim Harris <jimharris@freebsd.org>
Subject:   Re: CACHE_LINE_SIZE on x86
Message-ID:  <201210250918.00602.jhb@freebsd.org>
In-Reply-To: <CAJP=Hc_F%2B-RdD=XZ7ikBKVKE_XW88Y35Xw0bYE6gGURLPDOAWw@mail.gmail.com>
References:  <CAJP=Hc_F%2B-RdD=XZ7ikBKVKE_XW88Y35Xw0bYE6gGURLPDOAWw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210250918.00602.jhb>