From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Rik van Riel <riel@surriel.com>,
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: Mon, 3 Aug 2026 15:44:06 +0100 [thread overview]
Message-ID: <anCn2Zol3HywR8Tk@lucifer> (raw)
In-Reply-To: <f31c2c50-2239-4fd2-be3d-dd70c3d6140a@kernel.org>
On Mon, Aug 03, 2026 at 02:33:35PM +0200, David Hildenbrand (Arm) wrote:
> On 8/1/26 14:25, Rik van Riel wrote:
> > On Sat, 2026-08-01 at 10:54 +0100, Lorenzo Stoakes (ARM) wrote:
> >>
> >> 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.
> >
> > LLMs can apply those rules, when expressed in a way
> > that they get interpreted unambiguously by the LLM.
> >
> > I'm slowly building up a collection of such rules
> > in the kernel-style repository.
> >
> > AI can write in any style you ask it to.
> >
> > /*
> > * Long in the Halls of Rq the weary wait,
> > * till __schedule, herald of the turning years,
> > * calls forth the next to walk the road of fate
> > * as prev fades west.
> > */
> >
> > AI can also flag such issues, once it knows to
> > look for them.
>
> Just the important note that people can use LLMs to make themselves
> more efficient (if they think so), but not by delegating the hard work
> of sifting through slop (code and/or comments) to the poor souls that have
> to review it.
>
> LLM exercises should be done behind closed curtains without us noticing.
>
> >
> >>
> >>>
> >>> 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 :)
> >
> > The 80/20 rule comes into play here.
> >
> > If AI produces junk, the person starting with
> > LLM-produced code can spend days cleaning it
> > up, without getting things in a reasonable state.
>
> Right. But what happens instead is that people think it's okay to not do
> that work and instead workslop us.
>
> That is simply not acceptable, and we'll have to start ignoring people
> where this is a recurring theme. We simply don't have the time to do other
> peoples work.
Yes exactly, this is the problem and this patch was a prime example of it.
The theme here is 'please don't add to the impossible review load' or you will
receive a >/dev/null resolution to the problem :)
>
> --
> Cheers,
>
> David
--
Cheers, Lorenzo
prev parent reply other threads:[~2026-08-03 14:44 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
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) [this message]
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=anCn2Zol3HywR8Tk@lucifer \
--to=ljs@kernel.org \
--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=peterx@redhat.com \
--cc=riel@surriel.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