From: Mike Kravetz <mike.kravetz@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
David Hildenbrand <david@redhat.com>,
Michal Hocko <mhocko@suse.com>,
Oscar Salvador <osalvador@suse.de>, Zi Yan <ziy@nvidia.com>,
Muchun Song <songmuchun@bytedance.com>,
Naoya Horiguchi <naoya.horiguchi@linux.dev>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH RESEND 0/8] hugetlb: add demote/split page functionality
Date: Mon, 16 Aug 2021 17:46:58 -0700 [thread overview]
Message-ID: <b4401912-b59a-2150-feef-468c2d25ba3e@oracle.com> (raw)
In-Reply-To: <20210816162749.22b921a61156a091f3e1d14d@linux-foundation.org>
On 8/16/21 4:27 PM, Andrew Morton wrote:
> Also, pushback...
That is welcome. I only have the one specific use case mentioned here.
>
> On Mon, 16 Aug 2021 15:49:45 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
>>
>> Real world use cases
>> --------------------
>> There are groups today using hugetlb pages to back VMs on x86. Their
>> use case is as described above. They have experienced the issues with
>> performance and not necessarily getting the excepted number smaller huge
>
> ("number of")
thanks, another typo to fix.
>
>> pages after free/allocate cycle.
>>
>
> It really is a ton of new code. I think we're owed much more detail
> about the problem than the above. To be confident that all this
> material is truly justified?
The desired functionality for this specific use case is to simply
convert a 1G huegtlb page to 512 2MB hugetlb pages. As mentioned
"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."
These two issues have been experienced in practice.
A big chunk of the code changes (aprox 50%) is for the vmemmap
optimizations. This is also the most complex part of the changes.
I added the code as interaction with vmemmap reduction was discussed
during the RFC. It is only a performance enhancement and honestly
may not be worth the cost/risk. I will get some numbers to measure
the actual benefit.
>
> Also, some selftests and benchmarking code in tools/testing/selftests
> would be helpful?
>
Will do.
--
Mike Kravetz
next prev parent reply other threads:[~2021-08-17 0:47 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-16 22:49 [PATCH RESEND 0/8] hugetlb: add demote/split page functionality Mike Kravetz
2021-08-16 22:49 ` [PATCH 1/8] hugetlb: add demote hugetlb page sysfs interfaces Mike Kravetz
2021-08-16 22:49 ` [PATCH 2/8] hugetlb: add HPageCma flag and code to free non-gigantic pages in CMA Mike Kravetz
2021-08-16 22:49 ` [PATCH 3/8] hugetlb: add demote bool to gigantic page routines Mike Kravetz
2021-08-16 22:49 ` [PATCH 4/8] hugetlb: add hugetlb demote page support Mike Kravetz
2021-08-16 22:49 ` [PATCH 5/8] hugetlb: document the demote sysfs interfaces Mike Kravetz
2021-08-16 23:28 ` Andrew Morton
2021-08-17 1:04 ` Mike Kravetz
2021-09-21 13:52 ` Aneesh Kumar K.V
2021-09-21 17:17 ` Mike Kravetz
2021-08-16 22:49 ` [PATCH 6/8] hugetlb: vmemmap optimizations when demoting hugetlb pages Mike Kravetz
2021-08-16 22:49 ` [PATCH 7/8] hugetlb: prepare destroy and prep routines for vmemmap optimized pages Mike Kravetz
2021-08-16 22:49 ` [PATCH 8/8] hugetlb: Optimized demote vmemmap optimizatized pages Mike Kravetz
2021-08-16 23:23 ` [PATCH RESEND 0/8] hugetlb: add demote/split page functionality Andrew Morton
2021-08-17 0:17 ` Mike Kravetz
2021-08-17 0:39 ` Andrew Morton
2021-08-17 0:58 ` Mike Kravetz
2021-08-16 23:27 ` Andrew Morton
2021-08-17 0:46 ` Mike Kravetz [this message]
2021-08-17 1:46 ` Andrew Morton
2021-08-17 7:30 ` David Hildenbrand
2021-08-17 16:19 ` Mike Kravetz
2021-08-17 18:49 ` David Hildenbrand
2021-08-24 22:08 ` Mike Kravetz
2021-08-26 7:32 ` Hillf Danton
2021-08-27 17:22 ` Vlastimil Babka
2021-08-27 23:04 ` Mike Kravetz
2021-08-30 10:11 ` Vlastimil Babka
2021-09-02 18:17 ` Mike Kravetz
2021-09-06 14:40 ` Vlastimil Babka
2021-09-07 8:50 ` Hillf Danton
2021-09-08 21:00 ` Mike Kravetz
2021-09-09 4:07 ` Hillf Danton
2021-09-09 11:54 ` Michal Hocko
2021-09-09 13:45 ` Vlastimil Babka
2021-09-09 21:31 ` Mike Kravetz
2021-09-10 8:20 ` Michal Hocko
2021-09-11 0:11 ` Mike Kravetz
2021-09-11 3:11 ` Hillf Danton
2021-09-13 15:50 ` Michal Hocko
2021-09-15 16:57 ` Mike Kravetz
2021-09-17 20:44 ` 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=b4401912-b59a-2150-feef-468c2d25ba3e@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=naoya.horiguchi@linux.dev \
--cc=osalvador@suse.de \
--cc=rientjes@google.com \
--cc=songmuchun@bytedance.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;
as well as URLs for NNTP newsgroup(s).