Date: Sat, 5 Jan 2013 13:54:02 -0800 From: Jason Evans <jasone@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-hackers@freebsd.org, Hakisho Nukama <nukama@gmail.com> Subject: Re: L1 cache thrashing affects performance of HIMENO benchmark Message-ID: <DFFCA030-3206-4EB2-88C8-262AB298FF9F@freebsd.org> In-Reply-To: <CAJ-Vmo=O9v==Xpm8F2UUjkEAOaHbKydLMpn6Bz-5rRBt%2B2TEAg@mail.gmail.com> References: <CA%2Bzcas1V0KzcBKjq1u3Rwu_Nm7hVkG%2BG%2BeHpHRDQG0_NcXoOWA@mail.gmail.com> <CAJ-Vmo=O9v==Xpm8F2UUjkEAOaHbKydLMpn6Bz-5rRBt%2B2TEAg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 5, 2013, at 12:47 PM, Adrian Chadd <adrian@freebsd.org> wrote: > On 5 January 2013 07:38, Hakisho Nukama <nukama@gmail.com> wrote: >> FreeBSD (PCBSD) is slower compared to Linux and kFreeBSD in this >> benchmark of HIMENO: >> = http://openbenchmarking.org/prospect/1202215-BY-FREEBSD9683/88ac7a01c6cb35= 5d7e7603224b2ee1e5a4cb881d >> Also DragonFly BSD compares worse to kFreeBSD and Linux: >> = http://www.phoronix.com/scan.php?page=3Darticle&item=3Ddragonfly_linux_32&= num=3D3 >> = http://openbenchmarking.org/prospect/1206255-SU-DRAGONFLY55/88ac7a01c6cb35= 5d7e7603224b2ee1e5a4cb881d >>=20 >> Matt, Venkatesh and Alex investigated this performance problem and >> came to these results: >> http://leaf.dragonflybsd.org/mailarchive/users/2013-01/msg00011.html >=20 > I've CC'ed jasone on this as it's an interesting side-effect of memory > allocation logic. >=20 > Jason - any comments? There are many variations on this class of performance problem, and the = short of it is that only the application can have adequate understanding = of data structure layout and access patterns to reliably make optimal = use of the cache. However, it is possible for the allocator to lay out = memory in a more haphazard fashion than jemalloc, phkmalloc, etc. do, = such that the application can be cache-oblivious and (usually) not = suffer worst case consequences as happened in this case. Extent-based = allocators like dlmalloc often get this "for free" for a significant = range of allocation sizes. jemalloc could be modified to this end, but = a full solution would necessarily increase internal fragmentation. It = might be worth experimenting with nonetheless. Thanks, Jason=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DFFCA030-3206-4EB2-88C8-262AB298FF9F>