Re: [PATCH RFC 05/13] mm/huge_memory: consolidate irq and locking for folio split

[Kairui Song]

On Sun, Aug 9, 2026 at 9:54 AM Zi Yan <ziy@xxxxxxxxxx> wrote:
>
> On Fri Aug 7, 2026 at 5:17 PM EDT, Kairui Song via B4 Relay wrote:
> > From: Kairui Song <kasong@xxxxxxxxxxx>
> >
> > Let each split helper handle its own locking instead of relying on
> > the caller, so both paths follow the same convention and __folio_split()
> > can drop its local irq handling and fail label, preparing for further
> > cleanup.
> >
> > Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>
> > ---
> >  mm/huge_memory.c | 52 ++++++++++++++++++++++++----------------------------
> >  1 file changed, 24 insertions(+), 28 deletions(-)
> >
>
> <snip>
>
> anon part is not changed.

Right, I can mention this in commit message.

>
> > @@ -4035,8 +4039,21 @@ static int __folio_freeze_split_unmapped_file(struct folio *folio, unsigned int
> >       struct lruvec *lruvec;
> >       int ret;
> >
> > -     if (!folio_ref_freeze(folio, folio_cache_ref_count(folio) + 1))
> > -             return -EAGAIN;
> > +     xas_lock_irq(xas);
>
> local_irq_disable() + xas_lock() is replaced by xas_lock_irq(). Are they
> equivalent? Codex told me that the latter no longer prevents preemption
> on RT kernel and can lengthen folio split process if it is preempted. It
> is worth spell out in the commit message after you verify it.

It's a typical RT tradeoff, but I think it's actually an improvement?
The old behavior was an actual RT anti-pattern, RT cares more about
latency. I also traced other freeze & filemap update user, most are
using xas_lock_irq, and that seems better. I'll mention this in commit
message.

> > +
> > +     /*
> > +      * Check if the folio is present in page cache.
> > +      * We assume all tail are present too, if folio is there.
> > +      */
>
> xas_reset() is gone here. It seems to be a no-op, since xas is not
> walked yet. But it is better to mention it in the commit message.

Will do.

Thanks for the review!