[Bug libc/25030] RFE: malloc() cache line alignment for larger allocations

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25030

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2019-09-24
                 CC|                            |carlos at redhat dot com
     Ever confirmed|0                           |1

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
The alignment of the allocations returned by glibc's malloc is based upon
max_align_t, and this happens to be 16-bytes (__alignof__ (long double)), and
is the smallest possible alignment required to still meet the requirements of
the standard (though jemalloc/tcamlloc use smaller alignment for smaller types
for compact representations with out-of-line metadata).

You can yourself play with changing this, edit
glibc/sysdeps/generic/malloc-alignment.h and change MALLOC_ALIGNMENT. The
problem here is going to be that the higher the number the more internal
fragmentation we might create, and so increase RSS usage, but also provide
better performance.

We might introduce a tunable to force cache aligned allocations at the cost of
memory, with heuristics to only use this for larger allocations e.g. only large
bins.

Have you taken a look at the tradeoff of internal fragmentation versus cache
line size? Do you have any suggestions for say x86_64? How big should the
allocation be before such an alignment is employed?

-- 
You are receiving this mail because:
You are on the CC list for the bug.