From owner-freebsd-arch@FreeBSD.ORG Thu Oct 25 02:12:11 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA2F8C6E for ; Thu, 25 Oct 2012 02:12:11 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 114E98FC12 for ; Thu, 25 Oct 2012 02:12:10 +0000 (UTC) Received: (qmail 37917 invoked from network); 25 Oct 2012 03:49:54 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Oct 2012 03:49:54 -0000 Message-ID: <50889FEE.50702@networx.ch> Date: Thu, 25 Oct 2012 04:11:58 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: CACHE_LINE_SIZE on x86 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Harris , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 02:12:11 -0000 On 24.10.2012 23:27, Adrian Chadd wrote: > On 24 October 2012 12:13, 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. > > Well, is it worth maintaining multiple alignment options, for aligning > different things? Unlikely. That's going to be far too specific on a particular micro- architecture. > eg cache alignment for memory allocations, larger alignment for > compile-time structure alignment, etc? That's handled in malloc() and UMA zones. Completely irrelevant here. -- Andre