From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Lance Yang <lance.yang@linux.dev>,
peterz@infradead.org, david@kernel.org, dave.hansen@intel.com,
dave.hansen@linux.intel.com, ypodemsk@redhat.com,
hughd@google.com, will@kernel.org, aneesh.kumar@kernel.org,
npiggin@gmail.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, x86@kernel.org, hpa@zytor.com, arnd@arndb.de,
ljs@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com,
Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com,
dev.jain@arm.com, baohua@kernel.org, shy828301@gmail.com,
riel@surriel.com, jannh@google.com, jgross@suse.com,
seanjc@google.com, pbonzini@redhat.com,
boris.ostrovsky@oracle.com, virtualization@lists.linux.dev,
kvm@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
ioworker0@gmail.com, roman.gushchin@linux.dev
Subject: Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
Date: Fri, 24 Apr 2026 13:37:04 +0000 [thread overview]
Message-ID: <aetw4aoABYj3keMh@plex> (raw)
In-Reply-To: <20260424063024.ce42ee6a5546e4d9337dd007@linux-foundation.org>
On 04-24 06:30, Andrew Morton wrote:
> On Fri, 24 Apr 2026 14:25:26 +0800 Lance Yang <lance.yang@linux.dev> wrote:
>
> > When page table operations require synchronization with software/lockless
> > walkers, they call tlb_remove_table_sync_{one,rcu}() after flushing the
> > TLB (tlb->freed_tables or tlb->unshared_tables).
> >
> > On architectures where the TLB flush already sends IPIs to all target CPUs,
> > the subsequent sync IPI broadcast is redundant. This is not only costly on
> > large systems where it disrupts all CPUs even for single-process page table
> > operations, but has also been reported to hurt RT workloads[1].
> >
> > This series introduces tlb_table_flush_implies_ipi_broadcast() to check if
> > the prior TLB flush already provided the necessary synchronization. When
> > true, the sync calls can early-return.
> >
> > A few cases rely on this synchronization:
> >
> > 1) hugetlb PMD unshare[2]: The problem is not the freeing but the reuse
> > of the PMD table for other purposes in the last remaining user after
> > unsharing.
> >
> > 2) khugepaged collapse[3]: Ensure no concurrent GUP-fast before collapsing
> > and (possibly) freeing the page table / re-depositing it.
>
> Sashiko questions:
> https://sashiko.dev/#/patchset/20260424062528.71951-1-lance.yang@linux.dev
>
> (I never know if my Sashiko emails are welcome/useful. Maybe Sashiko
> said the same stuff about v9 and it's all wrong. But better safe than
> sorry!)
These emails are helpful; but, I do not believe you should have to
manually follow up with a link to every new patch series.
Perhaps Sashiko could automatically send a summary email in response to
the cover letter, or provide a link once the reviews are complete. For
the kexec ML, we opted-in with Roman to receive automated emails from
sashiko.
+Cc: Roman.
>
>
next prev parent reply other threads:[~2026-04-24 13:37 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 6:25 [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them Lance Yang
2026-04-24 6:25 ` [PATCH 7.2 v10 1/2] mm/mmu_gather: prepare to skip redundant sync IPIs Lance Yang
2026-04-24 15:04 ` Peter Zijlstra
2026-04-24 15:52 ` Dave Hansen
2026-04-24 15:40 ` Lance Yang
2026-04-24 6:25 ` [PATCH 7.2 v10 2/2] x86/tlb: skip redundant sync IPIs for native TLB flush Lance Yang
2026-04-24 15:12 ` Peter Zijlstra
2026-04-24 15:49 ` Lance Yang
2026-04-24 13:30 ` [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them Andrew Morton
2026-04-24 13:37 ` Pasha Tatashin [this message]
2026-04-24 14:15 ` Andrew Morton
2026-04-24 14:20 ` David Hildenbrand (Arm)
2026-04-24 14:31 ` Andrew Morton
2026-04-24 14:40 ` Pasha Tatashin
2026-04-24 18:36 ` David Hildenbrand (Arm)
2026-04-24 18:50 ` Yosry Ahmed
2026-04-24 19:01 ` Peter Zijlstra
2026-04-24 19:12 ` Zi Yan
2026-04-24 19:15 ` Yosry Ahmed
2026-04-25 0:58 ` SeongJae Park
2026-04-24 19:22 ` Peter Zijlstra
2026-04-24 19:35 ` Peter Zijlstra
2026-04-24 20:03 ` Roman Gushchin
2026-04-24 20:11 ` Peter Zijlstra
2026-04-24 19:08 ` Andrew Morton
2026-04-24 19:09 ` David Hildenbrand (Arm)
2026-04-24 19:17 ` Peter Zijlstra
2026-04-24 19:24 ` David Hildenbrand (Arm)
2026-04-24 19:18 ` Yosry Ahmed
2026-04-25 1:12 ` SeongJae Park
2026-04-25 5:17 ` David Hildenbrand (Arm)
2026-04-25 11:36 ` Andrew Morton
2026-04-27 8:53 ` David Hildenbrand (Arm)
2026-04-25 1:19 ` SeongJae Park
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=aetw4aoABYj3keMh@plex \
--to=pasha.tatashin@soleen.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=arnd@arndb.de \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=ioworker0@gmail.com \
--cc=jannh@google.com \
--cc=jgross@suse.com \
--cc=kvm@vger.kernel.org \
--cc=lance.yang@linux.dev \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mingo@redhat.com \
--cc=npache@redhat.com \
--cc=npiggin@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=roman.gushchin@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=seanjc@google.com \
--cc=shy828301@gmail.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux.dev \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=ypodemsk@redhat.com \
--cc=ziy@nvidia.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.