Date: Tue, 6 Nov 2012 14:35:25 -0700 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "Rodney W. Grimes" <freebsd@pdx.rh.cn85.chatusa.com>, Juli Mallett <juli@clockworksquid.com>, "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org> Subject: Re: CACHE_LINE_SIZE macro. Message-ID: <2E046873-B6A1-4F9C-8F3C-1CE6E60C6BF7@bsdimp.com> In-Reply-To: <CAJ-Vmon7p_MbtqnFPUd0Cy4RrReOKyrAB095k27GiOR0Uyh_gA@mail.gmail.com> References: <B4225C25-BD43-423C-A1A2-C9FD4AC92ECB@bsdimp.com> <201211051201.qA5C1rIo094612@pdx.rh.CN85.ChatUSA.com> <CAJ-Vmon7p_MbtqnFPUd0Cy4RrReOKyrAB095k27GiOR0Uyh_gA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <freebsd@pdx.rh.cn85.chatusa.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2E046873-B6A1-4F9C-8F3C-1CE6E60C6BF7>