Bug 2116464

Summary:	Backport tunable "glibc.malloc.hugetlb" in GLIBC 2.34
Product:	Red Hat Enterprise Linux 9	Reporter:	Ankur deDev <ankur.dedev>
Component:	glibc	Assignee:	glibc team <glibc-bugzilla>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-tools-bugs
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	9.0	CC:	ashankar, brault, codonell, dcain, dj, fweimer, mnewsome, pfrankli, sipoyare
Target Milestone:	rc	Keywords:	Patch, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-11-10 16:22:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ankur deDev 2022-08-08 14:49:20 UTC

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.

Comment 1 Carlos O'Donell 2022-08-08 16:09:00 UTC

(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.

Comment 4 Ankur deDev 2022-08-11 13:34:29 UTC

@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.

Comment 9 Florian Weimer 2022-11-10 16:22:20 UTC

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.

Comment 10 Ankur deDev 2022-11-10 17:08:53 UTC

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?