RHEL 9 comes with GLIBC 2.34. Starting with this version of GLIBC, the __morecore malloc hooks were removed. The change has in turn resulted in the impossibility to compile the libhugetlbfs. Probably for that reason, the libhugetlbfs was removed from RHEL 9. To provide an alternative for the users (including libhugetlbfs), GLIBC has implemented a new tunable called "glibc.malloc.hugetlb" (see at the bottom of the page here: https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.html). This new tunable will allow users to instruct malloc to use huge pages. You can find some background about this story here (https://github.com/libhugetlbfs/libhugetlbfs/issues/52). The problem is that this new tunable got released with the GLIBC 2.35 and therefore is absent from RHEL 9. That's why it would be great to backport this new tunable in the version of GLIBC used by RHEL 9 and release it. This would allow users to immediately get back one of the main benefits of libhugetlbfs (i.e. an heap allocator backed by huge pages). Later down the road it might also help to recover the entire libhugetlbfs.
(In reply to Ankur deDev from comment #0) > The problem is that this new tunable got released with the GLIBC 2.35 and > therefore is absent from RHEL 9. That's why it would be great to backport > this new tunable in the version of GLIBC used by RHEL 9 and release it. This > would allow users to immediately get back one of the main benefits of > libhugetlbfs (i.e. an heap allocator backed by huge pages). Later down the > road it might also help to recover the entire libhugetlbfs. Thanks for submitting this. We'll review this as part of our ongoing RHEL9 triage. Is there a specific use case that you have that was improved by libhugetlbfs? We are always interested in knowing which use cases or workloads we should be looking at.
@codonell Thanks a lot for your answer, I started to draft an answer and as it grew bigger than what is probably acceptable for this forum I'll be sending through another channel.
We have reviewed this enhancement request for inclusion into Red Hat Enterprise Linux 9 and have decided not include at this point. Affected customers and partners are kindly requested to provide feedback on this decision using the official support channels.
Hi Florian, thanks for the feedback on this ticket. This is obviously not the one we were expecting because it means that migrating to RHEL 9 (if possible at all) will require us to write a dedicated memory allocator for our software (waiting for RHEL 10 might be a better option at this point). Has Carlos shared with you the software I sent him to illustrate the performance impact this decision may have in practice? If not, I can send it to you as well if you want to have a look. Also, could you please indicate here what are the "official support channels" that you are referring to?