Re: [PATCH RFC] mm/gup: batch contiguous pages in follow_page_mask() and return them via a pages array

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Jul 31, 2026 at 02:32:58PM -0400, Rik van Riel wrote:
> 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.

Thanks for doing a human pass but it LLM's habits really carried through
here. In general:

- No walls of text please - fewer words are better, clarity is king.

- Don't write the code in English as a comment/commit msg - redudant and
  distracting.

- Sensible patch separation obviously please.

- Write as elegant/reasonable code as possible. If the code you touch was
  some horrible mega-function, take the time to refactor it. Pay down
  technical debt.

These are all things LLMs are extremely bad at (even fable). So they need
to be done by a human.

>
> 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.

OK I guess we'll see on respin about the comments.

>
> > And at least use a reasonable model - sonnet isn't intended for
> > kernel
> > development is it?
>
> Also, I have found that while Opus tends to make fewer
> mistakes than Sonnet, they both produce unreadable LLM
> output when left alone.

Unfortunately based on your recent submissions I don't agree.

In general, even with fable, I've found that the code it generates is
nowhere near kernel quality.

I'd suggest using the generated code as guidance only and the LLM for
checking things rather than making things.

>
> 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.

I mean, sure, but what's needed here is human Rik :)

>
>
> 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.

Well as you can tell I'm not afraid to - well I wouldn't say yell, more
civilised than that - protest :)

In general, again, the human layer is what's needed here not more rules
IMO.

Reviewer/submitter asymmetry was already a huge problem, AI slop makes it
critical and means people repeatedly submitting things that look like that
will get rejected out of hand.

Let's try to avoid that here :)

>
> --
> All Rights Reversed.

--
Cheers, Lorenzo