From: Mike Kravetz <mike.kravetz@oracle.com>
To: luofei <luofei@unicloud.com>
Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev>,
Miaohe Lin <linmiaohe@huawei.com>,
songmuchun@bytedance.com, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm, hwpoison, hugetlb: Free hwpoison huge page to list tail and dissolve hwpoison huge page first
Date: Tue, 2 Aug 2022 09:58:55 -0700 [thread overview]
Message-ID: <YulXz+1iLHuZBEDb@monkey> (raw)
In-Reply-To: <20220802100711.2425644-1-luofei@unicloud.com>
On 08/02/22 06:07, luofei wrote:
> If free hwpoison huge page to the end of hugepage_freelists, the
> loop can exit directly when the hwpoison huge page is traversed,
> which can effectively reduce the repeated traversal of the hwpoison
> huge page. Meanwhile, when free the free huge pages to lower level
> allocators, if hwpoison ones are released first, this can improve
> the effecvive utilization rate of huge page.
In general, I think this is a good idea. Although, it seems that with
recent changes to hugetlb poisioning code we are even less likely to
have a poisioned page on hugetlb free lists.
Adding Naoya and Miaohe as they have been looking at page poison of hugetlb
pages recently.
> Signed-off-by: luofei <luofei@unicloud.com>
> ---
> mm/hugetlb.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 28516881a1b2..ca72220eedd9 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1116,7 +1116,10 @@ static void enqueue_huge_page(struct hstate *h, struct page *page)
> lockdep_assert_held(&hugetlb_lock);
> VM_BUG_ON_PAGE(page_count(page), page);
>
> - list_move(&page->lru, &h->hugepage_freelists[nid]);
> + if (unlikely(PageHWPoison(page)))
> + list_move_tail(&page->lru, &h->hugepage_freelists[nid]);
> + else
> + list_move(&page->lru, &h->hugepage_freelists[nid]);
> h->free_huge_pages++;
> h->free_huge_pages_node[nid]++;
> SetHPageFreed(page);
> @@ -1133,7 +1136,7 @@ static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid)
> continue;
>
> if (PageHWPoison(page))
> - continue;
> + break;
IIRC, it is 'possible' to unpoison a page via the debug/testing interfaces.
If so, then we could end up with free unpoisioned page(s) at the end of
the list that would never be used because we quit when encountering a
poisioned page.
Naoya and Miaohe would know for sure.
Same possible issue in demote_pool_huge_page().
--
Mike Kravetz
>
> list_move(&page->lru, &h->hugepage_activelist);
> set_page_refcounted(page);
> @@ -2045,7 +2048,7 @@ static struct page *remove_pool_huge_page(struct hstate *h,
> */
> if ((!acct_surplus || h->surplus_huge_pages_node[node]) &&
> !list_empty(&h->hugepage_freelists[node])) {
> - page = list_entry(h->hugepage_freelists[node].next,
> + page = list_entry(h->hugepage_freelists[node].prev,
> struct page, lru);
> remove_hugetlb_page(h, page, acct_surplus);
> break;
> @@ -3210,7 +3213,7 @@ static void try_to_free_low(struct hstate *h, unsigned long count,
> for_each_node_mask(i, *nodes_allowed) {
> struct page *page, *next;
> struct list_head *freel = &h->hugepage_freelists[i];
> - list_for_each_entry_safe(page, next, freel, lru) {
> + list_for_each_entry_safe_reverse(page, next, freel, lru) {
> if (count >= h->nr_huge_pages)
> goto out;
> if (PageHighMem(page))
> @@ -3494,7 +3497,7 @@ static int demote_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
> for_each_node_mask_to_free(h, nr_nodes, node, nodes_allowed) {
> list_for_each_entry(page, &h->hugepage_freelists[node], lru) {
> if (PageHWPoison(page))
> - continue;
> + break;
>
> return demote_free_huge_page(h, page);
> }
> --
> 2.27.0
>
next prev parent reply other threads:[~2022-08-02 16:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-02 10:07 [PATCH] mm, hwpoison, hugetlb: Free hwpoison huge page to list tail and dissolve hwpoison huge page first luofei
2022-08-02 16:58 ` Mike Kravetz [this message]
2022-08-04 2:08 ` Miaohe Lin
2022-08-04 5:32 ` 答复: " 罗飞
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=YulXz+1iLHuZBEDb@monkey \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luofei@unicloud.com \
--cc=naoya.horiguchi@linux.dev \
--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.