Re: [PATCH RFC] mm/gup: batch contiguous pages in follow_page_mask() and return them via a pages array
From: Rik van Riel
Date: Fri Jul 31 2026 - 14:45:28 EST
On Fri, 2026-07-31 at 13:33 +0100, Lorenzo Stoakes (ARM) wrote:
> > mm/gup.c | 539 +++++++++++++++++++++++++++++++++------------------
> > ----
>
> OK it seems the message isn't really getting through...
>
> You really have to spend at least some time filtering this LLM-
> generated
> stuff.
>
I spent a fair amount of time cleaning up the code
and comments. Arguably the new code is cleaner than
the old code was.
However, I do agree this patch is too big. That won't
happen again.
> Nobody's got time for walls of text and giant changes like this.
>
I had no idea how to split it up when I made it,
but have found a few ways now.
I've split up the patch into a series of 5 now:
1) mm/gup: convert follow_page_mask() to return a long
2) mm/gup: split follow_page_pte_commit() out of follow_page_pte()
3) mm/gup: add gup_fill_pages() and use it
4) mm/gup: return a huge page's full count from follow_page_mask()
5) mm/gup: walk multiple PTEs per follow_page_pte() call
The changelogs naturally got shorter with things
split up this way.
> And at least use a reasonable model - sonnet isn't intended for
> kernel
> development is it?
>
Sonnet 5 seems to be about on par with Opus 4.7 from
last year. The difference is not that dramatic.
Also, I have found that while Opus tends to make fewer
mistakes than Sonnet, they both produce unreadable LLM
output when left alone.
In order for them to produce code that is at least a
good starting point for editing, they need to follow
rules.
Once you apply the rules, Opus and Sonnet do not
produce results that are all that different from
each other.
I just added a few new rules, so the tooling won't
even let me create too-large patches any more.
Whenever you see me, or somebody else, produce
something wrong, either with or without an LLM,
please yell at me, so I can add the proper rules
to kernel-style (creation side), or review-prompts
(review side), so those things get caught
automatically in the future, and not sent to the
list.
--
All Rights Reversed.