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

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Hi Cupertino,

> I had a test application demonstrating the problem.

So I don't see the problem discussed of huge pages being
split into small pages due to the guard page. If you ask for
N huge pages of stack, you actually get either N-1 or N huge
pages. That's irrespectively of the size of the guard page.

If you get N-1 huge pages the first/last part of the stack consist
of small pages. This depends on the alignment of the previous
mmap by accident since the stack allocation code does not
request huge pages (ie. you get transparent huge pages if they
happen to fit in the mmap range).

Even in your basic example you always get exactly 1 huge page
for all threads when the mmap is aligned. Interestingly in the
unaligned mmap case (ie. N-1 huge pages), the RSS size can
actually end up twice as large as the RSS size of aligned huge
pages (eg. if you use ~2MBytes of stack it will exactly fit in one
huge page if aligned, so 2MB RSS, but if not aligned might use
1.9MB of small pages with the rest falling into the next huge
page, making RSS ~4MB).

So the underlying problem is that the stack allocation code doesn't
really support huge pages. It's bad to get random huge pages in
stack allocations based on alignment from unrelated mmap calls -
it affects RSS size randomly as well as TLB misses etc. Overall it seems
best to disable huge pages in stacks until this is fixed.

Cheers,
Wilco