Re: [PATCH v2 0/4] malloc: Improve Huge Page support

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 19/08/2021 09:26, Siddhesh Poyarekar wrote:
> On 8/19/21 5:34 PM, Adhemerval Zanella wrote:
>> I think this would be an additional tunable, we still need to handle
>> the case where mmap() fails either in default path (due maximum number
>> of mmap() per process by kernel or when the poll is exhausted for
>> MAP_HUGETLB).
>>
>> So for sbrk() call, should we align the increment to huge page and
>> issue the madvise() if the tunable is set to use huge pages?
> 
> Yeah it's a reasonable compromise.  I've been thinking about getting rid of max_mmaps too; I don't see much use for it anymore.

I think it made sense when mmap() is way costly, specially for 32-bit
architectures.  On Linux it is still controlled by a tunable,
/proc/sys/vm/max_map_count, so it might still be case where might
want to avoid the overhead of the mmap failure and fallback to sbrk()
directly.

But I agree that for usual case where mmap() is used it does not make
much sense to try use the tunable, since for cases like threaded
programs sbrk() does not help much.