linux-kernel - Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4ae28031-6cee-59b4-94d1-832290d7813c@oracle.com>
Date:   Wed, 10 Mar 2021 11:45:22 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        David Hildenbrand <david@...hat.com>,
        Oscar Salvador <osalvador@...e.de>, Zi Yan <ziy@...dia.com>,
        David Rientjes <rientjes@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

On 3/10/21 8:23 AM, Michal Hocko wrote:
> On Mon 08-03-21 16:18:52, Mike Kravetz wrote:
> [...]
>> Converting larger to smaller hugetlb pages can be accomplished today by
>> first freeing the larger page to the buddy allocator and then allocating
>> the smaller pages.  However, there are two issues with this approach:
>> 1) This process can take quite some time, especially if allocation of
>>    the smaller pages is not immediate and requires migration/compaction.
>> 2) There is no guarantee that the total size of smaller pages allocated
>>    will match the size of the larger page which was freed.  This is
>>    because the area freed by the larger page could quickly be
>>    fragmented.
> 
> I will likely not surprise to show some level of reservation. While your
> concerns about reconfiguration by existing interfaces are quite real is
> this really a problem in practice? How often do you need such a
> reconfiguration?

In reply to one of David's comments, I mentioned that we have a product
group with this use case today.  They use hugetlb pages to back VMs,
and preallocate a 'best guess' number of pages of each each order.  They
can only guess how many pages of each order are needed because they are
responding to dynamic requests for new VMs.

When they find themselves in this situation today, they free 1G pages to
buddy and try to allocate the corresponding number of 2M pages.  The
concerns above were mentioned/experienced by this group.

Part of the reason for the RFC was to see if others might have similar
use cases.  With newer x86 processors, I hear about more people using
1G hugetlb pages.  I also hear about people using hugetlb pages to back
VMs.  So, was thinking others may have similar use cases?

> Is this all really worth the additional code to something as tricky as
> hugetlb code base?
> 

The 'good news' is that this does not involve much tricky code.  It only
demotes free hugetlb pages.  Of course, it is only worth it the new code
is actually going to be used.  I know of at least one use case.
-- 
Mike Kravetz