From owner-freebsd-mips@FreeBSD.ORG Tue Nov 6 21:32:24 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4864E12E for ; Tue, 6 Nov 2012 21:32:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1304B8FC0C for ; Tue, 6 Nov 2012 21:32:24 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so688829pad.13 for ; Tue, 06 Nov 2012 13:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=n3nZn0PFLHaWqtJvm1sPUYyt71e+3hgIFfjtl2gsB5M=; b=kVv6h4Y0Ny/qCzVSfjsVEqp+LMR1voN8orh144eE4EOx6jnvtmS8+Ql8In0j6qv/lq lKLuCHIHzZdWjun47FAa1eQ8EtDMhbQJ+KmPhSMP2dFhU4JUM8h/Cz4sJxMPQjsXho3e +XsYUPr+qpOsZKKtFJ/W0yh5xSpA9LmT7LUQRdtlFkWpDkH9YBsaqwJklOmfSKAMpelQ TdVfj6ErCN5AB981V8sb+A1lhoAG4/qPjH51GtRSEgz95kiwnv8Mpc9kurn/9Y1xklnP /ztG7hmNXVJKIvFeKW3c/kJ3w/erknXqLvQgq9o6sa7hrUaaf4bb13r3UucNeiXTmAGd EhKA== MIME-Version: 1.0 Received: by 10.68.238.199 with SMTP id vm7mr7091453pbc.105.1352237543867; Tue, 06 Nov 2012 13:32:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Tue, 6 Nov 2012 13:32:23 -0800 (PST) In-Reply-To: <201211051201.qA5C1rIo094612@pdx.rh.CN85.ChatUSA.com> References: <201211051201.qA5C1rIo094612@pdx.rh.CN85.ChatUSA.com> Date: Tue, 6 Nov 2012 13:32:23 -0800 X-Google-Sender-Auth: M5v6MdWpPDu1wMEbU6yVmwQwBew Message-ID: Subject: Re: CACHE_LINE_SIZE macro. From: Adrian Chadd To: "Rodney W. Grimes" Content-Type: text/plain; charset=ISO-8859-1 Cc: Juli Mallett , "freebsd-mips@FreeBSD.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 21:32:24 -0000 On 5 November 2012 04:01, Rodney W. Grimes wrote: > I did not see -any- data presented that showed how this was proven to be of benifit. The intel guys didn't post data, but they did do their investigations. > Why not just go out and cache align every data structure in the kernel.... :-) A benchmark well show an improvement I am sure of that. > This may actually be begging for the old technique of carefull handcrafted structs that are such that things LIKE mutexes naturally end up > on a proper boundary. I bet you the boundary is actually 4 byte, independent of cache line size. Andre at least has noticed that ordering of things in the text section of the kernel (ie, what decisions are made at compile/link time) are actually causing measurable performance changes. And I think the compiler is naturally aligning these things in multiples of 4 bytes. The multi-core, multi-system architectures seem to be behaving slightly crazier than one expects.. where things like the contention is done not based on cache size, but by some larger chunk (256 bytes?). I'm not up to date on this stuff; Juli and Warner would know better than I. TL;DR - yes, more data is needed, but please don't discount the impact of not cache aligning these shared structures. Adrian