The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Rik van Riel <riel@surriel.com>,
	"Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: 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 14:33:35 +0200	[thread overview]
Message-ID: <f31c2c50-2239-4fd2-be3d-dd70c3d6140a@kernel.org> (raw)
In-Reply-To: <517bf6a8072a6e66f28f8ec08bec4b604f29491d.camel@surriel.com>

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.

-- 
Cheers,

David

  reply	other threads:[~2026-08-03 12:33 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) [this message]
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=f31c2c50-2239-4fd2-be3d-dd70c3d6140a@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=aris@ruivo.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 \
    --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