From: Oscar Salvador <osalvador@suse.de>
To: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org,
bp@alien8.de, mingo@redhat.com,
Thomas Gleixner <tglx@linutronix.de>,
pawan.kumar.gupta@linux.intel.com, mchehab+huawei@kernel.org,
paulmck@kernel.org, viro@zeniv.linux.org.uk,
Peter Zijlstra <peterz@infradead.org>,
luto@kernel.org, oneukum@suse.com, jroedel@suse.de,
Matthew Wilcox <willy@infradead.org>,
David Rientjes <rientjes@google.com>,
Mina Almasry <almasrymina@google.com>,
Randy Dunlap <rdunlap@infradead.org>,
anshuman.khandual@arm.com, Michal Hocko <mhocko@suse.com>,
"Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>,
Xiongchun duan <duanxiongchun@bytedance.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-doc@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [External] Re: [PATCH v7 00/15] Free some vmemmap pages of hugetlb page
Date: Mon, 7 Dec 2020 19:38:14 +0100 [thread overview]
Message-ID: <20201207183814.GA3786@localhost.localdomain> (raw)
In-Reply-To: <CAMZfGtX2mu1tyE_898mQeEpmP4Pd+rEKOHpYF=KN=5v4WExpig@mail.gmail.com>
On Fri, Dec 04, 2020 at 11:39:31AM +0800, Muchun Song wrote:
> On Fri, Dec 4, 2020 at 7:49 AM Mike Kravetz <mike.kravetz@oracle.com> wrote:
> > As previously mentioned, I feel qualified to review the hugetlb changes
> > and some other closely related changes. However, this patch set is
> > touching quite a few areas and I do not feel qualified to make authoritative
> > statements about them all. I too hope others will take a look.
>
> Agree. I also hope others can take a look at other modules(e.g.
> sparse-vmemmap, memory-hotplug). Thanks for everyone's efforts
> on this.
I got sidetracked by some other stuff but I plan to continue reviewing
this series.
One thing that came to my mind is that if we do as David suggested in
patch#4, and we move it towards the end to actually __enable__ this
once all the infrastructure is there (unless hstate->nr_vmemmap_pages
differs from 0 we should not be doing any work AFAIK), we could also
move patch#6 to the end (right before the enablement), kill patch#7
and only leave patch#13.
The reason for that (killing patch#7 and leaving patch#13 only)
is that it does not make much sense to me to disable PMD-mapped vmemmap
depending on the CONFIG_HUGETLB_xxxxx as that is enabled by default
to replace that later by the boot kernel parameter.
It looks more natural to me to disable it when we introduce the kernel
boot parameter, before the actual enablement of the feature.
As I said, I plan to start the review again, but the order above would
make more sense to me.
thanks
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2020-12-07 18:39 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 15:18 [PATCH v7 00/15] Free some vmemmap pages of hugetlb page Muchun Song
2020-11-30 15:18 ` [PATCH v7 01/15] mm/memory_hotplug: Move bootmem info registration API to bootmem_info.c Muchun Song
2020-12-07 12:12 ` David Hildenbrand
2020-11-30 15:18 ` [PATCH v7 02/15] mm/memory_hotplug: Move {get,put}_page_bootmem() " Muchun Song
2020-12-07 12:14 ` David Hildenbrand
2020-12-07 12:16 ` [External] " Muchun Song
2020-11-30 15:18 ` [PATCH v7 03/15] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2020-12-07 12:19 ` David Hildenbrand
2020-12-07 12:42 ` [External] " Muchun Song
2020-12-07 12:47 ` David Hildenbrand
2020-12-07 13:22 ` Muchun Song
2020-11-30 15:18 ` [PATCH v7 04/15] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate Muchun Song
2020-12-07 12:36 ` David Hildenbrand
2020-12-07 13:11 ` [External] " Muchun Song
2020-12-09 8:54 ` David Hildenbrand
2020-12-09 9:27 ` Muchun Song
2020-11-30 15:18 ` [PATCH v7 05/15] mm/bootmem_info: Introduce {free,prepare}_vmemmap_page() Muchun Song
2020-12-07 12:39 ` David Hildenbrand
2020-12-07 13:23 ` [External] " Muchun Song
2020-12-09 7:36 ` Muchun Song
2020-12-09 8:49 ` David Hildenbrand
2020-12-09 9:25 ` Muchun Song
2020-12-09 9:32 ` David Hildenbrand
2020-12-09 9:43 ` Muchun Song
2020-11-30 15:18 ` [PATCH v7 06/15] mm/hugetlb: Disable freeing vmemmap if struct page size is not power of two Muchun Song
2020-12-09 9:57 ` David Hildenbrand
2020-12-09 10:03 ` [External] " Muchun Song
2020-12-09 10:06 ` David Hildenbrand
2020-12-09 10:10 ` David Hildenbrand
2020-12-09 10:16 ` Muchun Song
2020-12-09 15:13 ` Muchun Song
2020-12-09 15:47 ` David Hildenbrand
2020-12-09 15:50 ` Muchun Song
2020-12-09 10:10 ` Muchun Song
2020-11-30 15:18 ` [PATCH v7 07/15] x86/mm/64: Disable PMD page mapping of vmemmap Muchun Song
2020-11-30 15:18 ` [PATCH v7 08/15] mm/hugetlb: Free the vmemmap pages associated with each hugetlb page Muchun Song
2020-11-30 15:18 ` [PATCH v7 09/15] mm/hugetlb: Defer freeing of HugeTLB pages Muchun Song
2020-11-30 15:18 ` [PATCH v7 10/15] mm/hugetlb: Allocate the vmemmap pages associated with each hugetlb page Muchun Song
2020-11-30 15:18 ` [PATCH v7 11/15] mm/hugetlb: Set the PageHWPoison to the raw error page Muchun Song
2020-11-30 15:18 ` [PATCH v7 12/15] mm/hugetlb: Flush work when dissolving hugetlb page Muchun Song
2020-11-30 15:18 ` [PATCH v7 13/15] mm/hugetlb: Add a kernel parameter hugetlb_free_vmemmap Muchun Song
2020-12-04 0:01 ` Song Bao Hua (Barry Song)
2020-11-30 15:18 ` [PATCH v7 14/15] mm/hugetlb: Gather discrete indexes of tail page Muchun Song
2020-11-30 15:18 ` [PATCH v7 15/15] mm/hugetlb: Add BUILD_BUG_ON to catch invalid usage of tail struct page Muchun Song
2020-12-03 8:35 ` [PATCH v7 00/15] Free some vmemmap pages of hugetlb page Muchun Song
2020-12-03 23:48 ` Mike Kravetz
2020-12-04 3:39 ` [External] " Muchun Song
2020-12-07 18:38 ` Oscar Salvador [this message]
2020-12-08 2:26 ` 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=20201207183814.GA3786@localhost.localdomain \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=anshuman.khandual@arm.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=duanxiongchun@bytedance.com \
--cc=hpa@zytor.com \
--cc=jroedel@suse.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=oneukum@suse.com \
--cc=paulmck@kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=song.bao.hua@hisilicon.com \
--cc=songmuchun@bytedance.com \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/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).