From: Oscar Salvador <osalvador@suse.de>
To: Muchun Song <songmuchun@bytedance.com>
Cc: akpm@linux-foundation.org, corbet@lwn.net, david@redhat.com,
mike.kravetz@oracle.com, paulmck@kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, duanxiongchun@bytedance.com,
smuchun@gmail.com
Subject: Re: [PATCH v5 2/2] mm: memory_hotplug: make hugetlb_optimize_vmemmap compatible with memmap_on_memory
Date: Wed, 22 Jun 2022 05:40:44 +0200 [thread overview]
Message-ID: <YrKPPBGsT25FQFww@localhost.localdomain> (raw)
In-Reply-To: <20220620110616.12056-3-songmuchun@bytedance.com>
On Mon, Jun 20, 2022 at 07:06:16PM +0800, Muchun Song wrote:
> For now, the feature of hugetlb_free_vmemmap is not compatible with the
> feature of memory_hotplug.memmap_on_memory, and hugetlb_free_vmemmap
> takes precedence over memory_hotplug.memmap_on_memory. However, someone
> wants to make memory_hotplug.memmap_on_memory takes precedence over
> hugetlb_free_vmemmap since memmap_on_memory makes it more likely to
> succeed memory hotplug in close-to-OOM situations. So the decision
> of making hugetlb_free_vmemmap take precedence is not wise and elegant.
> The proper approach is to have hugetlb_vmemmap.c do the check whether
> the section which the HugeTLB pages belong to can be optimized. If
> the section's vmemmap pages are allocated from the added memory block
> itself, hugetlb_free_vmemmap should refuse to optimize the vmemmap,
> otherwise, do the optimization. Then both kernel parameters are
> compatible. So this patch introduces VmemmapSelfHosted to mask any
> non-optimizable vmemmap pages. The hugetlb_vmemmap can use this flag
> to detect if a vmemmap page can be optimized.
>
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> Co-developed-by: Oscar Salvador <osalvador@suse.de>
> Signed-off-by: Oscar Salvador <osalvador@suse.de>
LGTM, thanks for working on this!
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2022-06-22 3:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 11:06 [PATCH v5 0/2] make hugetlb_optimize_vmemmap compatible with memmap_on_memory Muchun Song
2022-06-20 11:06 ` [PATCH v5 1/2] mm: memory_hotplug: enumerate all supported section flags Muchun Song
2022-06-21 7:39 ` David Hildenbrand
2022-06-20 11:06 ` [PATCH v5 2/2] mm: memory_hotplug: make hugetlb_optimize_vmemmap compatible with memmap_on_memory Muchun Song
2022-06-20 13:19 ` Oscar Salvador
2022-06-20 14:15 ` Muchun Song
2022-06-21 7:39 ` David Hildenbrand
2022-06-22 3:40 ` Oscar Salvador [this message]
2022-06-21 20:53 ` [PATCH v5 0/2] " Andrew Morton
2022-06-22 3:31 ` Muchun Song
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=YrKPPBGsT25FQFww@localhost.localdomain \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=duanxiongchun@bytedance.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=paulmck@kernel.org \
--cc=smuchun@gmail.com \
--cc=songmuchun@bytedance.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.