[PATCH v2 0/4] malloc: Improve Huge Page support
Adhemerval Zanella
adhemerval.zanella@linaro.org
Thu Aug 19 17:27:00 GMT 2021
On 19/08/2021 14:17, Guillaume Morin wrote:
> On 19 Aug 13:55, Adhemerval Zanella wrote:
>> On 19/08/2021 13:42, Guillaume Morin wrote:
>>> Are you planning on tackling using the same tunables to allocate
>>> additional heaps (in arena.c)?
>>>
>>> It's a little more subtle because of the calls to mprotect() which needs
>>> to be properly aligned for hugetlbfs, and probably for THP as well (to
>>> avoid un-necessary page splitting).
>>
>> What do you mean by additional heaps in this case?
>
> I mean what is done in new_heap() in arena.c.
Good catch, I haven't take in consideration the new_heap() code. I think
we should the same tunable to drive the hguepage usage in this case as
well.
>
>>> One additional thing to address is the case where mmap() fails with
>>> MAP_HUGETLB because HP allocation fails. Reverting to the default pages
>>> will match what libhugetlbfs does (i.e just call mmap() again without
>>> MAP_HUGETLB). But I see that Siddhesh and you have already been
>>> discussing this case.
>>
>> This is what I did in my patch, it follow the current default allocation
>> path.
>
> Yes, you are right. I misread. You've been discussing adding a tunable
> to decide if that should fail or not. My 2 cents as a user: it's hard
> for me to imagine that users would like malloc() to fail in this case.
> Even if the admin allows surplus pages (i.e create new HPs on the fly),
> this is far from guaranteed to succeed.
>
> Guillaume.
>
More information about the Libc-alpha
mailing list