Re: [PATCH RFC 01/18] x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()
Mike Rapoport <[email protected]> Tue, 21 Jul 2026 21:30:26 +0300
| Newsgroups | dev.linux.lists.loongarch,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Jul 21, 2026 at 06:16:33PM +0100, Lorenzo Stoakes (ARM) wrote: > On Tue, Jul 21, 2026 at 07:23:24PM +0300, Mike Rapoport (Microsoft) wrote: > > The splitting and merging of kernel page table mappings between small and > > large is protected by cpa_lock. The merging is relatively new but the > > splitting is ancient. > > > > The splitting has a locking optimization: since DEBUG_PAGEALLOC forces all > > mappings to 4k, there are no large pages to split. So the code that *might* > > cause a split can just skip the locking (and a few other things). > > > > This is entertaining, but it adds complexity and makes for weird locking > > rules. Plus it's all for a debugging feature which makes the kernel super > > slow in the first place. Optimizing something which is already super slow > > and not used in production is not the best way to spend our complexity > > budget. > > > > Stop gating cpa_lock on debug_pagealloc_enabled() to simplify the code > > and the locking rules. > > > > [ dhansen: flesh out changelog ] > > > > Suggested-by: Dave Hansen <[email protected]> > > Signed-off-by: Mike Rapoport (Microsoft) <[email protected]> > > Signed-off-by: Dave Hansen <[email protected]> > > Link: https://patch.msgid.link/[email protected] > > Link: https://lore.kernel.org/all/[email protected]/ > > Hmm this patch is already taken separately though? ([0]) (obv. commented there > already with review feedback). > > Intended to be with this series as some kind of background or? Probably better > to separate out given it's a live patch From the cover letter: Patch 1 is already applied to the tip tree and I posted patch 2 separately [4], but I included them both here for the completeness. > Thanks, Lorenzo -- Sincerely yours, Mike.