From: Oscar Salvador <osalvador@suse.de>
To: Muchun Song <songmuchun@bytedance.com>
Cc: "Mike Kravetz" <mike.kravetz@oracle.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Thomas Gleixner" <tglx@linutronix.de>,
mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
dave.hansen@linux.intel.com, luto@kernel.org,
"Peter Zijlstra" <peterz@infradead.org>,
viro@zeniv.linux.org.uk,
"Andrew Morton" <akpm@linux-foundation.org>,
paulmck@kernel.org, mchehab+huawei@kernel.org,
pawan.kumar.gupta@linux.intel.com,
"Randy Dunlap" <rdunlap@infradead.org>,
oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de,
"Mina Almasry" <almasrymina@google.com>,
"David Rientjes" <rientjes@google.com>,
"Matthew Wilcox" <willy@infradead.org>,
"Michal Hocko" <mhocko@suse.com>,
"Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>,
"David Hildenbrand" <david@redhat.com>,
"HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>,
"Joao Martins" <joao.m.martins@oracle.com>,
"Xiongchun duan" <duanxiongchun@bytedance.com>,
linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
"Linux Memory Management List" <linux-mm@kvack.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [External] Re: [PATCH v16 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page
Date: Wed, 24 Feb 2021 09:31:49 +0100 [thread overview]
Message-ID: <20210224083145.GA14894@linux> (raw)
In-Reply-To: <CAMZfGtUBMzAgPVgm=9wgJg+yytxwSGOK_BVOw93RPLb3_tFS_g@mail.gmail.com>
On Wed, Feb 24, 2021 at 11:47:49AM +0800, Muchun Song wrote:
> I have been looking at the dequeue_huge_page_node_exact().
> If a PageHWPoison huge page is in the free pool list, the page will
> not be allocated to the user. The PageHWPoison huge page
> will be skip in the dequeue_huge_page_node_exact().
Yes, now I see where the problem lies.
hugetlb_no_page()->..->dequeue_huge_page_node_exact() will fail if the only
page in the pool is hwpoisoned, as expected.
Then alloc_buddy_huge_page_with_mpol() will be tried, but since surplus_huge_pages
counter is stale, we will fail there.
That relates to the problem Mike pointed out, that we should decrease again the
surplus_huge_pages.
I think hwpoisoned pages should not be in the free pool though.
Probably we want to take them off when we notice we have one:
e.g: dequeue_huge_page_node_exact could place the page in another list
and place it back in case it was unpoisoned.
But anyway, that has nothing to do with this (apart from the surplus problem).
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2021-02-24 8:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 10:49 [PATCH v16 0/9] Free some vmemmap pages of HugeTLB page Muchun Song
2021-02-19 10:49 ` [PATCH v16 1/9] mm: memory_hotplug: factor out bootmem core functions to bootmem_info.c Muchun Song
2021-02-19 10:49 ` [PATCH v16 2/9] mm: hugetlb: introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2021-02-19 10:49 ` [PATCH v16 3/9] mm: hugetlb: free the vmemmap pages associated with each HugeTLB page Muchun Song
2021-02-19 10:49 ` [PATCH v16 4/9] mm: hugetlb: alloc " Muchun Song
2021-02-19 14:12 ` Michal Hocko
2021-02-20 4:20 ` [External] " Muchun Song
2021-02-22 9:25 ` Michal Hocko
2021-02-22 10:31 ` Muchun Song
2021-02-22 10:50 ` Oscar Salvador
2021-02-23 0:00 ` Mike Kravetz
2021-02-23 5:35 ` [External] " Muchun Song
2021-02-23 9:27 ` Oscar Salvador
2021-02-23 10:27 ` [External] " Muchun Song
2021-02-23 10:50 ` Oscar Salvador
2021-02-23 15:41 ` Oscar Salvador
2021-02-23 22:31 ` Oscar Salvador
2021-02-24 3:47 ` Muchun Song
2021-02-24 8:31 ` Oscar Salvador [this message]
2021-02-19 10:49 ` [PATCH v16 5/9] mm: hugetlb: set the PageHWPoison to the raw error page Muchun Song
2021-02-19 10:49 ` [PATCH v16 6/9] mm: hugetlb: add a kernel parameter hugetlb_free_vmemmap Muchun Song
2021-02-19 10:49 ` [PATCH v16 7/9] mm: hugetlb: introduce nr_free_vmemmap_pages in the struct hstate Muchun Song
2021-02-19 10:49 ` [PATCH v16 8/9] mm: hugetlb: gather discrete indexes of tail page Muchun Song
2021-02-19 10:49 ` [PATCH v16 9/9] mm: hugetlb: optimize the code with the help of the compiler 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=20210224083145.GA14894@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=joao.m.martins@oracle.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).