From: Muchun Song <songmuchun@bytedance.com>
To: Mike Kravetz <mike.kravetz@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Oscar Salvador <osalvador@suse.de>,
Michal Hocko <mhocko@suse.com>,
"Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>,
David Hildenbrand <david@redhat.com>,
Chen Huang <chenhuang5@huawei.com>,
"Bodeddula, Balasubramaniam" <bodeddub@amazon.com>,
Jonathan Corbet <corbet@lwn.net>,
Xiongchun duan <duanxiongchun@bytedance.com>,
fam.zheng@bytedance.com, linux-doc@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [External] Re: [PATCH v2 0/3] Split huge PMD mapping of vmemmap pages
Date: Tue, 15 Jun 2021 13:37:15 +0800 [thread overview]
Message-ID: <CAMZfGtU3=9JUVj5a7fFo_1K18yOcU4+9c5R2goXVwsGGJxLvNw@mail.gmail.com> (raw)
In-Reply-To: <fe65a409-b989-5e05-952e-6fcf6aa2ab55@oracle.com>
On Tue, Jun 15, 2021 at 11:52 AM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> On 6/14/21 6:12 PM, Andrew Morton wrote:
> > On Sat, 12 Jun 2021 17:45:52 +0800 Muchun Song <songmuchun@bytedance.com> wrote:
> >
> >> In order to reduce the difficulty of code review in series[1]. We disable
> >> huge PMD mapping of vmemmap pages when that feature is enabled. In this
> >> series, we do not disable huge PMD mapping of vmemmap pages anymore. We
> >> will split huge PMD mapping when needed. When HugeTLB pages are freed from
> >> the pool we do not attempt coalasce and move back to a PMD mapping because
> >> it is much more complex.
> >>
> >> [1] https://lore.kernel.org/linux-doc/20210510030027.56044-1-songmuchun@bytedance.com/
> >
> > [1] had a nice [0/n] description but the v2 series lost that. I could
> > copy/paste the v1 changelogging but I am unsure that it has been
> > maintained appropriately for the v2 series.
> >
> > I think I'll pass on this v2 pending additional review input. Please reinstate
> > the [0/n] overview if/when resending?
>
> There may be some confusion.
>
> This series is a follow on optimization for the functionality provided by
> [1]. Early in the development of [1], it was decided to drop some code
> for ease of review. Specifically, splitting vmemmap PMD mappings to PTE
> mappings as required when hugetlb pages were allocated. The
> 'simplification' in [1] is that if the feature is enabled then vmemmap
> will only be mapped with PTEs.
>
> This series provides the ability to split PMD mappings 'on demand' as
> hugetlb pages are allocated. As mentioned, it really is a follow on and
> optimization to functionality provided in [1]. As such, I am not sure
> that repeating the [0/n] description from 1 is necessary here.
>
> In any case, this should be clearly stated in the [0/n] description of
> this series.
Thanks for the clarification for me. I totally agree with you.
>
> BTW- I did get through the series today, and did not discover any
> issues. However, I want to sleep on it before signing off.
> --
> Mike Kravetz
prev parent reply other threads:[~2021-06-15 5:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-12 9:45 [PATCH v2 0/3] Split huge PMD mapping of vmemmap pages Muchun Song
2021-06-12 9:45 ` [PATCH v2 1/3] mm: sparsemem: split the " Muchun Song
2021-06-15 22:31 ` Mike Kravetz
2021-06-16 3:23 ` [External] " Muchun Song
2021-06-12 9:45 ` [PATCH v2 2/3] mm: sparsemem: use huge PMD mapping for " Muchun Song
2021-06-12 9:45 ` [PATCH v2 3/3] mm: hugetlb: introduce CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON Muchun Song
2021-06-15 23:00 ` Joao Martins
2021-06-16 3:04 ` [External] " Muchun Song
2021-06-15 1:12 ` [PATCH v2 0/3] Split huge PMD mapping of vmemmap pages Andrew Morton
2021-06-15 3:52 ` Mike Kravetz
2021-06-15 5:37 ` Muchun Song [this message]
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='CAMZfGtU3=9JUVj5a7fFo_1K18yOcU4+9c5R2goXVwsGGJxLvNw@mail.gmail.com' \
--to=songmuchun@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=bodeddub@amazon.com \
--cc=chenhuang5@huawei.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=duanxiongchun@bytedance.com \
--cc=fam.zheng@bytedance.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=osalvador@suse.de \
--cc=song.bao.hua@hisilicon.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.