mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: Wentao Guan <guanwentao@uniontech.com>
Cc: mike.kravetz@oracle.com, osalvador@suse.de, david@kernel.org,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb: avoid unnecessary TLB flush for empty folio list in vmemmap optimize
Date: Tue, 30 Jun 2026 20:00:51 +0800	[thread overview]
Message-ID: <6FEB0F1B-CFD6-4999-A9D6-CBDEF9951C8A@linux.dev> (raw)
In-Reply-To: <20260630113857.3319612-1-guanwentao@uniontech.com>



> On Jun 30, 2026, at 19:38, Wentao Guan <guanwentao@uniontech.com> wrote:
> 
> __hugetlb_vmemmap_optimize_folios() unconditionally issues a final
> flush_tlb_all() in its out path.  However, a TLB flush must be paired
> with an actual page table modification.
> 
> When the input folio list is empty, neither PMD splitting nor PTE
> remapping takes place, so no page tables are modified and the flush is
> pure overhead.  An empty list is reached in common paths such as
> gather_bootmem_prealloc_node() on nodes without bootmem gigantic pages,
> hugetlb_pages_alloc_boot_node() when no pages were allocated, and
> runtime allocation failure paths in set_max_huge_pages().
> 
> Add an early return for empty lists.  This restores the basic invariant
> that TLB flushes are only issued when page tables have been modified,
> and it also makes the NULL hstate passed by gather_bootmem_prealloc_node()
> on an empty list harmless.
> 
> Assisted-by: kimi-cli:kimi-k2.7 code
> Assisted-by: Github Copilot:gpt-5.2 #Reported-by
> 
> Fixes: 79359d6d24df ("hugetlb: perform vmemmap optimization on a list of pages")

Actually, this is an optimization, so it doesn't need a bugfix—unless it's a hot
path or causing a massive performance degradation, that's clearly not the case
here.

> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>

I actually have a local optimization that covers this, so LGTM:

Reviewed-by: Muchun Song <muchun.song@linux.dev>

Thanks.


      reply	other threads:[~2026-06-30 12:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30 11:38 Wentao Guan
2026-06-30 12:00 ` Muchun Song [this message]

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=6FEB0F1B-CFD6-4999-A9D6-CBDEF9951C8A@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=guanwentao@uniontech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=osalvador@suse.de \
    /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

Powered by JetHome