[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5e576e6750f4ead28c94d7a54600dad875a75083.camel@infradead.org>
Date: Mon, 07 Apr 2025 09:01:19 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Mike Rapoport <rppt@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, "Sauerwein, David"
<dssauerw@...zon.de>, Anshuman Khandual <anshuman.khandual@....com>, Ard
Biesheuvel <ardb@...nel.org>, Catalin Marinas <catalin.marinas@....com>,
David Hildenbrand <david@...hat.com>, Marc Zyngier <maz@...nel.org>, Mark
Rutland <mark.rutland@....com>, Mike Rapoport <rppt@...ux.ibm.com>, Will
Deacon <will@...nel.org>, kvmarm@...ts.cs.columbia.edu,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [RFC PATCH v2 4/7] mm: Optimise SPARSEMEM implementation of
for_each_valid_pfn()
On Mon, 2025-04-07 at 10:07 +0300, Mike Rapoport wrote:
> On Fri, Apr 04, 2025 at 04:59:56PM +0100, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@...zon.co.uk>
> >
> > There's no point in checking the section and subsection bitmap for *every*
> > PFN in the same section; they're either all valid or they aren't.
>
> Don't you want to merge this with the previous commit?
Maybe. Or at least the previous commit should be using the 'return -1'
model to minimise the differences.
To start with though, I wanted it to be reviewable as an incremental
patch to what we'd already been discussing. (And I figured there was at
least a non-zero chance of you not liking it just because it's too
complex, so the whole thing is easy to drop this way).
Even after review, keeping it as a separate patch means it's easily
revertible if we find we want to go back to the simpler version.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)
Powered by blists - more mailing lists