Date: Mon, 5 Nov 2012 12:01:41 -0500 From: Eitan Adler <lists@eitanadler.com> To: Warner Losh <imp@bsdimp.com> 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: <CAF6rxg=Et1d6u4RBCB88KibW_uiaRbNdb75v0TQOr-0BrEXV=g@mail.gmail.com> In-Reply-To: <DAE462F0-9D85-4942-8826-C0709E36D3B7@bsdimp.com> References: <CACVs6=_BrwJ19CPj7OqKvV8boHfujVWqn96u3VPUmZ040JpAeQ@mail.gmail.com> <201211041828.qA4ISomC076058@pdx.rh.CN85.ChatUSA.com> <CAF6rxgn-bNJOuvdiRj_UUGQUTRaeOt54OdzHOioNz5f566hoig@mail.gmail.com> <DAE462F0-9D85-4942-8826-C0709E36D3B7@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 November 2012 11:49, Warner Losh <imp@bsdimp.com> wrote: >> There has been some discussion recently about padding lock mutexs to >> the cache line size in order to avoid false sharing of CPUs. Some have >> claimed to see significant performance increases as a result. > > Is that an out-of-kernel interface? > > If we did that, we'd have to make it run-time settable, because there's no one right answer for arm and MIPS cpus: they are all different. The discussion ended up with using a special parameter CACHE_LINE_SIZE_LOCKS which is different than CACHE_LINE_SIZE. This is necessary for other reasons as well (CACHE_LINE_SIZE_LOCKS may take into account prefetching of cache lines, but CACHE_LINE_SIZE wouldn't). I think the "correct" thing to do here is choose a reasonable, but not-always-correct CACHE_LINE_SIZE_LOCKS and make CACHE_LINE_SIZE a per-board constant (or run time setting, or whatever works). You can't make it run-time settable as the padding is part of the ABI: For more details see http://comments.gmane.org/gmane.os.freebsd.devel.cvs/483696 which contains the original discussion. Note - I was not involved. -- Eitan Adler
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF6rxg=Et1d6u4RBCB88KibW_uiaRbNdb75v0TQOr-0BrEXV=g>