Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


      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