From: "Theodore Tso" <tytso@mit.edu>
To: Konstantin Ryabitsev <mricon@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Sasha Levin <sashal@kernel.org>,
ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc
Date: Fri, 17 Jul 2026 16:21:19 -0400 [thread overview]
Message-ID: <alp-zVPGXg0Hub5e@mit.edu> (raw)
In-Reply-To: <20260717-hissing-successful-rabbit-fecc0c@lemur>
On Fri, Jul 17, 2026 at 09:55:02AM -0500, Konstantin Ryabitsev wrote:
> I'd go so far as to say that we DON'T want to feed unfiltered LKML archives
> into the model -- we probably want to lean on the work done by the cregit
> folks to identify patch sets that were actually accepted and then work
> backwards, creating a subset of LKML that resulted in accepted contributions.
I agree that we can do better by tagging various e-mails from the LKML
archives as "this commit was rejected" or "the patch or e-mail was
ignored because it was obviously AI SLOP" or "this is a review by
someone who is known to be a bad reviewer such that maintiners have
stock e-mails explaining to new contributors that it's OK to ignore
reviews from that reviewer".
> (Not that any other AI companies are bothered with this detail, as they are
> scraping everything as fast as they can.)
Yeah, precisely.
The frontier models are trained by grabbing everything, and that's
what the kernel review prompts use. If we use one of the smaller
models that can fit in smaller machines, those smaller models won't
have as much of the "knowledge" that was gained by the training that
was done by scraping everything, since the smaller models were created
by distilling the larger models. Detailed knowledge about Linux kenel
would be diminished along with the distillation process --- along with
all other bits of knowledge, including internal combustion engines,
how to create meth, etc. So we could add it back via the fine tuning
process. More information can be found here[1].
[1] https://unsloth.ai/docs/get-started/fine-tuning-llms-guide/datasets-guide
If we do this, it's probably not the patches which are the most
interesting, it would be the review comments, since that would inform
the model about what maintainers worry about when they are reviewing
code.
Note that there are multiple kinds of fine-tuning. One approach just
simply sends unstructured text in small chunks. There are more
powerful ways which require a lot more structuring where we give it
instruction and answer pairs[2].
[2] https://wandb.ai/capecape/alpaca_ft/reports/How-to-Fine-Tune-an-LLM-Part-1-Preparing-a-Dataset-for-Instruction-Tuning--Vmlldzo1NTcxNzE2
So there are many different ways that we could feed data when we do
the fine tuning, and I think we'd need to experiment a bit to see what
works.
Of course, we can also do this by enhancing the prompts that we give
to the review bot, but this chews up context window space, and
information in the review prompts have to be processed for every
single patch being reviewed. (Possibly multiple times if the review
bot using multiple passes.)
- Ted
next prev parent reply other threads:[~2026-07-17 20:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 15:09 [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc Jonathan Corbet
2026-07-16 15:28 ` Sasha Levin
2026-07-16 16:08 ` Mark Brown
2026-07-16 16:24 ` Sasha Levin
2026-07-16 20:38 ` Laurent Pinchart
2026-07-17 14:09 ` Sasha Levin
2026-07-17 14:25 ` Mark Brown
2026-07-16 18:36 ` Jonathan Corbet
2026-07-16 19:53 ` Mauro Carvalho Chehab
2026-07-16 23:59 ` Theodore Tso
2026-07-17 0:58 ` Mauro Carvalho Chehab
2026-07-17 2:27 ` Theodore Tso
2026-07-17 7:19 ` Mauro Carvalho Chehab
2026-07-17 13:55 ` Konstantin Ryabitsev
2026-07-17 14:24 ` Andrew Lunn
2026-07-17 14:32 ` Konstantin Ryabitsev
2026-07-17 14:50 ` Andrew Lunn
2026-07-17 20:21 ` Theodore Tso [this message]
2026-07-16 20:05 ` Bart Van Assche
2026-07-16 20:52 ` James Bottomley
2026-07-16 20:23 ` Liam R. Howlett
2026-07-17 7:49 ` Laurent Pinchart
2026-07-17 15:55 ` Liam R. Howlett
2026-07-17 11:57 ` James Bottomley
2026-07-17 15:53 ` Liam R. Howlett
2026-07-17 18:12 ` James Bottomley
2026-07-17 18:27 ` Dan Carpenter
2026-07-17 18:42 ` James Bottomley
2026-07-17 14:54 ` Johannes Weiner
2026-07-17 16:09 ` Liam R. Howlett
2026-07-16 21:23 ` Theodore Tso
2026-07-17 13:59 ` Sasha Levin
2026-07-17 14:09 ` Konstantin Ryabitsev
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=alp-zVPGXg0Hub5e@mit.edu \
--to=tytso@mit.edu \
--cc=corbet@lwn.net \
--cc=ksummit@lists.linux.dev \
--cc=mchehab+huawei@kernel.org \
--cc=mricon@kernel.org \
--cc=sashal@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.