linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Jinjiang Tu <tujinjiang@huawei.com>
Cc: david@redhat.com, akpm@linux-foundation.org,
	muchun.song@linux.dev, linux-mm@kvack.org,
	wangkefeng.wang@huawei.com
Subject: Re: [PATCH v3] mm/hugetlb: fix set_max_huge_pages() when there are surplus pages
Date: Tue, 8 Apr 2025 15:10:09 +0200	[thread overview]
Message-ID: <Z_UgMShiDLf-Eh_9@localhost.localdomain> (raw)
In-Reply-To: <20250407124706.2688092-1-tujinjiang@huawei.com>

On Mon, Apr 07, 2025 at 08:47:06PM +0800, Jinjiang Tu wrote:
> In set_max_huge_pages(), min_count should mean the acquired persistent
> huge pages, but it contains surplus huge pages. It will leads to failing
> to freeing free huge pages for a Node.
> 
> Steps to reproduce:
> 1) create 5 hugetlb folios in Node0
> 2) run a program to use all the hugetlb folios
> 3) echo 0 > nr_hugepages for Node0 to free the hugetlb folios. Thus the 5
> hugetlb folios in Node0 are accounted as surplus.
> 4) create 5 hugetlb folios in Node1
> 5) echo 0 > nr_hugepages for Node1 to free the hugetlb folios
> 
> The result:
>         Node0    Node1
> Total     5         5
> Free      0         5
> Surp      5         5

I would put this after the explanation, as otherwise is a bit hard to
follow.

> We couldn't subtract surplus_huge_pages from min_mount, since free hugetlb
> folios may be surplus due to HVO. In __update_and_free_hugetlb_folio(),
> hugetlb_vmemmap_restore_folio() may fail, add the folio back to pool and
> treat it as surplus. If we directly subtract surplus_huge_pages from
> min_mount, some free folios will be subtracted twice.
> 
> To fix it, check if count is less than the num of free huge pages that
> could be destroyed (i.e., available_huge_pages(h)), and remove hugetlb
> folios if so.

But this is not true, you are no longer comparing against
available_huge_pages(h) as you did in v2.

I would go with something along these lines as changelog.

"In set_max_huge_pages(), min_count is computed taking into account also
 surplushuge pages, which might lead in some cases to not be able to free
 huge pages and end up accounting them as surplus intead.

 One way to solve it is to substract surplus_huge_pages directly, but we
 cannot do it blindly because there might be surplus pages thar are also
 free pages, which might happen when we fail to restore the vmemmap for
 optimized hvo pages.
 So we could be subtracting the same page twice.

 In order to work this around, let us first compute the number of
 free persistent pages, and use that along with surplus pages
 to compute min_count."

 And then put the PoC.

> Fixes: 9a30523066cd ("hugetlb: add per node hstate attributes")
> Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>

Acked-by: Oscar Salvador <osalvador@suse.de>


-- 
Oscar Salvador
SUSE Labs


  reply	other threads:[~2025-04-08 13:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-07 12:47 Jinjiang Tu
2025-04-08 13:10 ` Oscar Salvador [this message]
2025-04-09  3:29   ` Jinjiang Tu

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=Z_UgMShiDLf-Eh_9@localhost.localdomain \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=tujinjiang@huawei.com \
    --cc=wangkefeng.wang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox