From owner-freebsd-mips@FreeBSD.ORG Tue Nov 6 21:35:30 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 41F5A187 for ; Tue, 6 Nov 2012 21:35:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id E960E8FC0C for ; Tue, 6 Nov 2012 21:35:29 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so1202123oag.13 for ; Tue, 06 Nov 2012 13:35:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=No/tfXs5iatYjAoaOB5wLElm48YO4KvZ4hB/+V91umc=; b=Ay6Hj4MwtmqSXeIwH7fhBljJENIH8lhODmz4+xSOiGmOv6/1KSK4B26pMDGQ7j0Mob eug8MTMCnpNrjh+MacM9v9M3XW30nhO3tcwY7JcI/Dr7Z5cdmK0AUigDO2wRegSs69jA tPNGemqDrPEI2n1dm+ECMIHkeCxjtGzXgzrg3L6B0W/lsHviJYuuG9X9SfJbGmaQSKTQ lnhnyMsLsHPdKDAkkZRLPLe+2tmuWjXHdCZoXFQKtJF9aM5u+9tjpA2Lnydci4WxLxE6 l0/5wSKmXZsGR4NCHirhuuk7kblqkjSz5viVB6RJBI6GFrBnscnKkJ1yQIJj7TffoML8 ZW2Q== Received: by 10.60.8.68 with SMTP id p4mr2076271oea.7.1352237729417; Tue, 06 Nov 2012 13:35:29 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id a7sm21801663obw.6.2012.11.06.13.35.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 13:35:28 -0800 (PST) Sender: Warner Losh Subject: Re: CACHE_LINE_SIZE macro. Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 6 Nov 2012 14:35:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E046873-B6A1-4F9C-8F3C-1CE6E60C6BF7@bsdimp.com> References: <201211051201.qA5C1rIo094612@pdx.rh.CN85.ChatUSA.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlS+kMrG7nSc0a8+QLS2g30BVuj3WDUfZau7Ox0UShEARGwXOSFRLS3X8ZmoX9BSHvkbrgw Cc: "Rodney W. Grimes" , 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:35:30 -0000 I think the real answer is to not abuse CACHE_LINE_SIZE for these things = at all, but make it a per-arch decision... That way mips32 could, for = example, not align and mips64 could if it wanted to... Having this be an ABI thing would be unfortunate. Warner On Nov 6, 2012, at 2:32 PM, Adrian Chadd wrote: > On 5 November 2012 04:01, Rodney W. Grimes > wrote: >=20 >> I did not see -any- data presented that showed how this was proven to = be of benifit. >=20 > The intel guys didn't post data, but they did do their investigations. >=20 >> 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. >=20 > 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. >=20 > And I think the compiler is naturally aligning these things in > multiples of 4 bytes. >=20 > 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. >=20 > TL;DR - yes, more data is needed, but please don't discount the impact > of not cache aligning these shared structures. >=20 >=20 > Adrian