[PATCH v5 1/1] Created tunable to force small pages on stack allocation.

Cupertino Miranda cupertino.miranda@oracle.com
Fri Apr 14 16:35:49 GMT 2023


Hi Wilco,

I had a test application demonstrating the problem.
I include it in attach.
>From my particular interest in the tunable this is the difference:

# GLIBC_TUNABLES=glibc.pthread.stack_hugetlb=0 ./tststackalloc 1
Page size: 4 kB, 2 MB huge pages
Will attempt to align allocations to make stacks eligible for huge pages
pid: 3482023 (/proc/3482023/smaps)
stack_size = 2097152, 0x200000
Creating 128 threads...
RSS: 448 pages (1835008 bytes = 1 MB)
Press enter to exit...

# GLIBC_TUNABLES=glibc.pthread.stack_hugetlb=1 ./tststackalloc 1
Page size: 4 kB, 2 MB huge pages
Will attempt to align allocations to make stacks eligible for huge pages
pid: 3482254 (/proc/3482254/smaps)
stack_size = 2097152, 0x200000
Creating 128 threads...
RSS: 65891 pages (269889536 bytes = 257 MB)
Press enter to exit...

Regards,
Cupertino

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tststackalloc.c
Type: text/x-csrc
Size: 4666 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20230414/c711d61b/attachment-0001.bin>
-------------- next part --------------


Wilco Dijkstra writes:

> Hi,
>
>> The next question is whether the splitting of one huge page causes the whole
>> stack mmap to use small pages too.
>
> Btw if it wasn't obvious, you can trivially check this by creating threads that use
> 3MB of stack. Then the RSS per thread should be either 3MB (only small pages,
> no RSS loss!), 4MB (2 large pages, no RSS loss), 5 MB (3MB small pages, 2MB loss)
> or 6MB (2 large pages, 2MB loss).
>
> Cheers,
> Wilco


More information about the Libc-alpha mailing list