From: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: Muchun Song <songmuchun@bytedance.com>,
corbet@lwn.net, mike.kravetz@oracle.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, viro@zeniv.linux.org.uk,
akpm@linux-foundation.org, paulmck@kernel.org,
mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com,
rdunlap@infradead.org, oneukum@suse.com,
anshuman.khandual@arm.com, jroedel@suse.de,
almasrymina@google.com, rientjes@google.com, willy@infradead.org,
mhocko@suse.com, song.bao.hua@hisilicon.com,
naoya.horiguchi@nec.com, duanxiongchun@bytedance.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v13 05/12] mm: hugetlb: allocate the vmemmap pages associated with each HugeTLB page
Date: Tue, 26 Jan 2021 16:34:52 +0100 [thread overview]
Message-ID: <20210126153448.GA17455@linux> (raw)
In-Reply-To: <259b9669-0515-01a2-d714-617011f87194@redhat.com>
On Tue, Jan 26, 2021 at 04:10:53PM +0100, David Hildenbrand wrote:
> The real issue seems to be discarding the vmemmap on any memory that has
> movability constraints - CMA and ZONE_MOVABLE; otherwise, as discussed, we
> can reuse parts of the thingy we're freeing for the vmemmap. Not that it
> would be ideal: that once-a-huge-page thing will never ever be a huge page
> again - but if it helps with OOM in corner cases, sure.
Yes, that is one way, but I am not sure how hard would it be to implement.
Plus the fact that as you pointed out, once that memory is used for vmemmap
array, we cannot use it again.
Actually, we would fragment the memory eventually?
> Possible simplification: don't perform the optimization for now with free
> huge pages residing on ZONE_MOVABLE or CMA. Certainly not perfect: what
> happens when migrating a huge page from ZONE_NORMAL to (ZONE_MOVABLE|CMA)?
But if we do not allow theose pages to be in ZONE_MOVABLE or CMA, there is no
point in migrate them, right?
> > > > Of course, this means that e.g: memory-hotplug (hot-remove) will not fully work
> > > > when this in place, but well.
> > >
> > > Can you elaborate? Are we're talking about having hugepages in
> > > ZONE_MOVABLE that are not migratable (and/or dissolvable) anymore? Than
> > > a clear NACK from my side.
> >
> > Pretty much, yeah.
>
> Note that we most likely soon have to tackle migrating/dissolving (free)
> hugetlbfs pages from alloc_contig_range() context - e.g., for CMA
> allocations. That's certainly something to keep in mind regarding any
> approaches that already break offline_pages().
Definitely. I already talked to Mike about that and I am going to have
a look into it pretty soon.
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2021-01-26 15:36 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-17 15:10 [PATCH v13 00/12] Free some vmemmap pages of HugeTLB page Muchun Song
2021-01-17 15:10 ` [PATCH v13 01/12] mm: memory_hotplug: factor out bootmem core functions to bootmem_info.c Muchun Song
2021-01-25 2:48 ` Miaohe Lin
2021-01-17 15:10 ` [PATCH v13 02/12] mm: hugetlb: introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2021-01-24 23:58 ` David Rientjes
2021-01-25 3:16 ` Randy Dunlap
2021-01-25 4:06 ` [External] " Muchun Song
2021-01-25 4:08 ` Randy Dunlap
2021-01-25 5:06 ` Muchun Song
2021-01-25 18:47 ` David Rientjes
2021-01-26 2:45 ` Muchun Song
2021-01-26 20:13 ` David Rientjes
2021-01-26 2:07 ` Miaohe Lin
2021-01-17 15:10 ` [PATCH v13 03/12] mm: hugetlb: free the vmemmap pages associated with each HugeTLB page Muchun Song
2021-01-17 15:29 ` Muchun Song
2021-01-23 0:59 ` Mike Kravetz
2021-01-23 3:22 ` [External] " Muchun Song
2021-01-23 17:52 ` Oscar Salvador
2021-01-24 6:48 ` [External] " Muchun Song
2021-01-17 15:10 ` [PATCH v13 04/12] mm: hugetlb: defer freeing of HugeTLB pages Muchun Song
2021-01-24 23:55 ` David Rientjes
2021-01-25 3:58 ` [External] " Muchun Song
2021-01-17 15:10 ` [PATCH v13 05/12] mm: hugetlb: allocate the vmemmap pages associated with each HugeTLB page Muchun Song
2021-01-25 0:05 ` David Rientjes
2021-01-25 6:40 ` [External] " Muchun Song
2021-01-25 7:41 ` Muchun Song
2021-01-25 9:15 ` David Hildenbrand
2021-01-25 9:34 ` Muchun Song
2021-01-25 23:25 ` Mike Kravetz
2021-01-26 7:48 ` Oscar Salvador
2021-01-26 9:29 ` Oscar Salvador
2021-01-26 9:36 ` David Hildenbrand
2021-01-26 14:58 ` Oscar Salvador
2021-01-26 15:10 ` David Hildenbrand
2021-01-26 15:34 ` Oscar Salvador [this message]
2021-01-26 15:56 ` David Hildenbrand
2021-01-27 10:36 ` David Hildenbrand
2021-01-28 12:37 ` [External] " Muchun Song
2021-01-28 13:08 ` Muchun Song
2021-01-29 1:04 ` Mike Kravetz
2021-01-29 6:56 ` Muchun Song
2021-02-01 16:10 ` David Hildenbrand
2021-02-02 0:05 ` Mike Kravetz
2021-01-28 22:29 ` Oscar Salvador
2021-01-29 6:16 ` [External] " Muchun Song
2021-02-01 15:50 ` David Hildenbrand
2021-01-17 15:10 ` [PATCH v13 06/12] mm: hugetlb: set the PageHWPoison to the raw error page Muchun Song
2021-01-25 0:06 ` David Rientjes
2021-01-25 5:06 ` [External] " Muchun Song
2021-01-17 15:10 ` [PATCH v13 07/12] mm: hugetlb: flush work when dissolving a HugeTLB page Muchun Song
2021-01-17 15:10 ` [PATCH v13 08/12] mm: hugetlb: introduce PageHugeInflight Muchun Song
2021-01-17 15:10 ` [PATCH v13 09/12] mm: hugetlb: add a kernel parameter hugetlb_free_vmemmap Muchun Song
2021-01-25 11:43 ` David Hildenbrand
2021-01-25 12:08 ` Oscar Salvador
2021-01-25 12:31 ` [External] " Muchun Song
2021-01-25 12:30 ` Muchun Song
2021-01-17 15:10 ` [PATCH v13 10/12] mm: hugetlb: introduce nr_free_vmemmap_pages in the struct hstate Muchun Song
2021-01-17 15:10 ` [PATCH v13 11/12] mm: hugetlb: gather discrete indexes of tail page Muchun Song
2021-01-17 15:10 ` [PATCH v13 12/12] mm: hugetlb: optimize the code with the help of the compiler Muchun Song
2021-01-20 12:52 ` [PATCH v13 00/12] Free some vmemmap pages of HugeTLB page Muchun Song
2021-01-20 13:10 ` Oscar Salvador
2021-01-20 14:22 ` [External] " 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=20210126153448.GA17455@linux \
--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=david@redhat.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=naoya.horiguchi@nec.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).