Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: David Hildenbrand <david@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jason Gunthorpe <jgg@ziepe.ca>, Peter Xu <peterx@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 kernel-team@meta.com, Aristeu Rozanski <aris@ruivo.org>
Subject: Re: [PATCH RFC] mm/gup: batch contiguous pages in follow_page_mask() and return them via a pages array
Date: Fri, 31 Jul 2026 14:32:58 -0400	[thread overview]
Message-ID: <e969b38ce882b32d041b7279499fddcd00f18b35.camel@surriel.com> (raw)
In-Reply-To: <amyUQahYOgov0z8c@lucifer>

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.


  reply	other threads:[~2026-07-31 18:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30  7:53 [PATCH RFC] mm/gup: batch contiguous pages in follow_page_mask() and return them via a pages array Rik van Riel
2026-07-31 12:33 ` Lorenzo Stoakes (ARM)
2026-07-31 18:32   ` Rik van Riel [this message]
2026-08-01  9:54     ` Lorenzo Stoakes (ARM)
2026-08-01 12:25       ` Rik van Riel
2026-08-03 12:33         ` David Hildenbrand (Arm)
2026-08-03 14:44           ` Lorenzo Stoakes (ARM)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e969b38ce882b32d041b7279499fddcd00f18b35.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=akpm@linux-foundation.org \
    --cc=aris@ruivo.org \
    --cc=david@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=peterx@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox