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] [day] [month] [year] [list]

Message-ID: <a1327057-621a-e5ae-6a9f-6d54e2041115@oracle.com>
Date:   Wed, 10 Mar 2021 11:56:51 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Zi Yan <ziy@...dia.com>, 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>,
        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:46 AM, Zi Yan wrote:
> The high level goal of this patchset seems to enable flexible huge page
> allocation from a single pool, when multiple huge page sizes are available
> to use. The limitation of existing mechanism is that user has to specify
> how many huge pages he/she wants and how many gigantic pages he/she wants
> before the actual use.
> 
> I just want to throw an idea here, please ignore if it is too crazy.
> Could we have a variant buddy allocator for huge page allocations,
> which only has available huge page orders in the free list? For example,
> if user wants 2MB and 1GB pages, the allocator will only have order-9 and
> order-19 pages; when order-9 pages run out, we can split order-19 pages;
> if possible, adjacent order-9 pages can be merged back to order-19 pages.

The idea is not crazy, but I think it is more functionality than we want
to throw at hugetlb.

IIRC, the default qemu huge page configuration uses THP.  Ideally, we
would have support for 1G THP pages and the user would not need to think
about any of this.  The kernel would back the VM with huge pages of the
appropriate size for best performance.

That may sound crazy, but I think it may be the looooong term goal.
-- 
Mike Kravetz