Date: Sat, 5 Jan 2013 18:03:04 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Jason Evans <jasone@freebsd.org> Cc: freebsd-hackers@freebsd.org, Hakisho Nukama <nukama@gmail.com> Subject: Re: L1 cache thrashing affects performance of HIMENO benchmark Message-ID: <CAJ-Vmo=nwQiDryXnU9RC3OOguM1XuN8xtSh0yjBGXOK3vgX2sg@mail.gmail.com> In-Reply-To: <DFFCA030-3206-4EB2-88C8-262AB298FF9F@freebsd.org> References: <CA%2Bzcas1V0KzcBKjq1u3Rwu_Nm7hVkG%2BG%2BeHpHRDQG0_NcXoOWA@mail.gmail.com> <CAJ-Vmo=O9v==Xpm8F2UUjkEAOaHbKydLMpn6Bz-5rRBt%2B2TEAg@mail.gmail.com> <DFFCA030-3206-4EB2-88C8-262AB298FF9F@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 January 2013 13:54, Jason Evans <jasone@freebsd.org> wrote: >> Jason - any comments? > > There are many variations on this class of performance problem, and the s= hort of it is that only the application can have adequate understanding of = data structure layout and access patterns to reliably make optimal use of t= he 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 ap= plication can be cache-oblivious and (usually) not suffer worst case conseq= uences as happened in this case. Extent-based allocators like dlmalloc oft= en get this "for free" for a significant range of allocation sizes. jemall= oc could be modified to this end, but a full solution would necessarily inc= rease internal fragmentation. It might be worth experimenting with nonethe= less. For at least this particular computational workload, the loss in throughput based on cache thrashing is significant enough to learn FreeBSD a negative mark in computational workloads. It'd be interesting to see which other workloads FreeBSD behaves poorly in. In fact, it'd be doubly interesting to get some people who _do_ computational workloads to do some profiling using oprofile/pmc and report back. Maybe if we wrote a wiki page on how to do this kind of profiling and how to interpret the results. In any case, yes - I think it's worth pursuing this further as it's very likely not the only workload that exhibits this kind of cache unhappiness. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=nwQiDryXnU9RC3OOguM1XuN8xtSh0yjBGXOK3vgX2sg>