From: Mike Kravetz <mike.kravetz@oracle.com>
To: Zi Yan <ziy@nvidia.com>, Michal Hocko <mhocko@suse.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
David Hildenbrand <david@redhat.com>,
Oscar Salvador <osalvador@suse.de>,
David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality
Date: Wed, 10 Mar 2021 11:56:51 -0800 [thread overview]
Message-ID: <a1327057-621a-e5ae-6a9f-6d54e2041115@oracle.com> (raw)
In-Reply-To: <298CE371-115E-4A78-A732-57D7B37DF74C@nvidia.com>
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
next prev parent reply other threads:[~2021-03-10 19:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 0:18 Mike Kravetz
2021-03-09 0:18 ` [RFC PATCH 1/3] hugetlb: add demote hugetlb page sysfs interfaces Mike Kravetz
2021-03-09 0:18 ` [RFC PATCH 2/3] hugetlb: add HPageCma flag and code to free non-gigantic pages in CMA Mike Kravetz
2021-03-09 0:18 ` [RFC PATCH 3/3] hugetlb: add hugetlb demote page support Mike Kravetz
2021-03-09 9:01 ` [RFC PATCH 0/3] hugetlb: add demote/split page functionality David Hildenbrand
2021-03-09 17:11 ` Mike Kravetz
2021-03-09 17:50 ` David Hildenbrand
2021-03-09 18:21 ` Mike Kravetz
2021-03-09 19:01 ` David Hildenbrand
2021-03-10 15:58 ` Oscar Salvador
2021-03-10 16:23 ` Michal Hocko
2021-03-10 16:46 ` Zi Yan
2021-03-10 17:05 ` Michal Hocko
2021-03-10 17:36 ` Zi Yan
2021-03-10 19:56 ` Mike Kravetz [this message]
2021-03-10 19:45 ` Mike Kravetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a1327057-621a-e5ae-6a9f-6d54e2041115@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=rientjes@google.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox