Date: Tue, 6 Nov 2012 13:32:23 -0800 From: Adrian Chadd <adrian@freebsd.org> To: "Rodney W. Grimes" <freebsd@pdx.rh.cn85.chatusa.com> Cc: Juli Mallett <juli@clockworksquid.com>, "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org> Subject: Re: CACHE_LINE_SIZE macro. Message-ID: <CAJ-Vmon7p_MbtqnFPUd0Cy4RrReOKyrAB095k27GiOR0Uyh_gA@mail.gmail.com> In-Reply-To: <201211051201.qA5C1rIo094612@pdx.rh.CN85.ChatUSA.com> References: <B4225C25-BD43-423C-A1A2-C9FD4AC92ECB@bsdimp.com> <201211051201.qA5C1rIo094612@pdx.rh.CN85.ChatUSA.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 November 2012 04:01, Rodney W. Grimes <freebsd@pdx.rh.cn85.chatusa.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon7p_MbtqnFPUd0Cy4RrReOKyrAB095k27GiOR0Uyh_gA>