Re: [RFC PATCH 0/8] Introducte Reserved THP

... digging through old mail.

> 
> You mean the reservation should be done via some file handle, like
> memfd, so that it is easy to apply memory policies to determine where
> reserved memory locates?
> 
> For existing hugetlb reservation, there is no fine control, like NUMA,
> or cgroup, of the reserved free memory.
> 
> Is that what you mean above?

I guess, it's all tricky. hugetlb reservation is a mess. We better not make
similar mistakes with THPs.

[...]

>>> 3.6 Remove Hugetlb
>>> ------------------
>>>
>>> Once reserved THP can completely replace the existing functions of hugetlb, we
>>> can gradually remove Hugetlb, leaving only one huge page management system in
>>> the kernel.
>>
>> I'm sorry, but no way this will work in any reasonable timeframe unless you
>> mimic the exact user facing ABI -- and I don't think we'll gain a lot that way.
>>
>> I know, we all like to dream, but this just isn't feasible.
> 
> Based on my understanding, the key takeway is that we want to have more
> control over reserved memory, where to get the free memory, who gets how
> much of the reserved memory, and more.

yes, it's all very complicated. Slapping on some MADV_RESERVED_THP is just
entirely the wrong way to tackle this.

-- 
Cheers,

David