Re: [PATCH v3] mm: unqueue deferred split folios outside the lruvec lock

[Andrew Morton]

On Wed, 21 Oct 2026 06:40:23 +0800 Barry Song <baohua@xxxxxxxxxx> wrote:

> > This is a speedup and not a correctness thing, yes?  Let's make it a
> > 7.4-rcX thing, for the 7.5 merge window.
> >
> > I'll park it in the mm-new branch for now.
> >
> > If people think the speedup is sufficiently worthwhile then I can add a
> > cc:stable to it, if clear justification is included in the changelog.
> 
> This isn't even a speedup at the moment, as no users have
> adopted it yet.
> 
> mTHP folios aren't currently added to the deferred split
> queue. Joanne is about to add >=2MB mTHP folios to the
> deferred split queue again, but even then, contention on
> the queue shouldn't be an issue.
> 
> It may become a problem someday when we add smaller large
> folios, such as 16KB folios, to the deferred split queue.
> So this patch is more about future-proofing.

Oh.  This:

: This came out of the discussion on v2 of the mTHP shrinker series [1],
: where queueing small mTHP folios on the deferred split queue was found
: to regress Barry's fault microbenchmark. With [1] applied and
: khugepaged/max_ptes_none=0 so that every folio is queued, perf lock
: contention showed that the extra cost came from waiting on the lruvec
: lock in the free path.

made it sound like an unquantified speedup.

Joanne, please clarify the expected impact (always) in the
changelogging if there are reasons for a v4.