On 10/10/22 04:54, Zhangfei Gao wrote:
> Hi, Adhemerval
>


Hi Zhangfei Gao,

> We are using libhugetlbfs feature to concur the tlb miss issue.
> LD_PRELOAD=/usr/lib/aarch64-linux-gnu/libhugetlbfs.so HUGETLB_MORECORE=yes app
>
> Happened to find morecore will be deprecated in glibc, 2.32+

The bug reports is incorrect, it was deprecated in glibc 2.34 and I
have implemented glibc.malloc.hugetlb for 2.35.  So only glibc 2.34 does
not have a way to explicit back up malloc allocation with hugetbl without
using a full allocation (such as jemalloc or tcmalloc).

> https://github.com/libhugetlbfs/libhugetlbfs/issues/52
>
> Thanks for your patch adding  glibc.malloc.hugetlb.
> But  still don't know how to use this feature.
>
>> If using glibc 2.35, do we still need libhugetlbfs.so?

It will depends whether your application need to use HUGETLB_ELFMAP and/or
HUGETLB_SHM since it is not implemented on glibc.  The HUGETLB_ELFMAP requires
a lot of hacks and kernel/toolchain have worked to make THP to work better
with text and data segments, and I think it is unlikely that we will support
on glibc anytime soon (it will most likely require changes in the ELF gnu
extension to explicit use huge pages).

For HUGETLB_SHM it should be easy to adapt the code to align to page size and
add SHM_HUGETLB. I think it might be doable to add support on glibc with an
extra tunable as well to avoid code changes in the application.  I still
prefer to adapt the the application itself because libhugetlbfs subtly change
shmget semantic under the hood (by changing memory alignment and segment).

>> Or just run "GLIBC_TUNABLES=glibc.malloc.hugetlb=2 app"?
Based on the command line you pasted, it should be only that.  It will cover
all memory allocation done by malloc.

>
> I am still in checking how to upgrading to glibc 2.35 in system.

Carlos O'Donnel from RH was thinking about backporting to old releases if