Re: Guideline change: glibc malloc as the C/C++/Rust allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* We have resources to support glibc malloc, but not for other mallocs.
* Other mallocs  do not follow ABI and provide insufficient alignment.
* Choosing a malloc is workload-dependent and forcing a non-default
   malloc takes options away from system administrators.

Could you please mention a couple of bugs where this is shown?

https://bugzilla.redhat.com/show_bug.cgi?id=1237260
https://bugzilla.redhat.com/show_bug.cgi?id=1303323
http://www.erahm.org/2016/03/24/minimum-alignment-of-allocation-across-platforms/

Always requiring 16-byte alignment on x86_64 can waste too much space
due to internal fragmentation.  The rule should be:
   The required alignment is at least  min(16, max_p2_divisor_of_size)
   where the second argument max_p2_divisor_of_size is the maximum power of 2
   that divides the requested size [when 0!= size].
Thus a request for 6 bytes may be satisfied by a block whose address is
divisible by 2.

This rule arises from consideration of how the requested size is calculated
for something expressible as C-language source.  If the requested size is the
sizeof() a primitive type, array, struct, or union, then the alignment of each
accessible element divides the requested size, and all alignment constraints
for access to elements are satisfied.  So if the requested size is sizeof()
any C-language construct, then all alignment constraints for all members
will be satisfied. If the requested size is not sizeof() any primitive type,
array, struct, or union, then the allocator may choose to align the result
based on the power-of-2 divisibility of the requested size.

If the C run-time library (or any other accessor) wishes to "over-fetch"
(fetch more than the size of a language element that could reside in
the block, or at an address which might not be the address
of such an element), such as in the name of speed or simplicity,
then the accessor must guard against the possibility of fetching across
a page or segment boundary.  Some string manipulators in glibc already
pay attention to fetching within the current cache line because of speed
advantages.  Fetching only within the current page is similar.

If the user source code desires higher alignment, then it is the source
code's responsibility to call posix_memalign, or to round up explicitly.
Some apps want small total space, even at the cost of a few cycles
for short duration in some places.  Requiring minimum alignment of 16
can make it too hard to achieve small total space.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/AKMSEI6KTNLJ53VLEGO2S2AWUDQCWWZ4/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux