[RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[gang.yan]

Hi all,

Apologies for the extra email, and please don't take this as any criticism of the current workflow.

I'm writing this email to see if anyone else in the community shares some confusion I have
regarding the use of Sashiko—specifically, the multiple rounds of iteration and the large
volume of emails generated on the main list.

Let me explain the problem more clearly.

The Problem

  Since Sashiko was introduced, it has greatly accelerated patch iteration for contributors.
  However, from a human reviewer's perspective, the main mailing list (mptcp@lists.linux.dev)
  now carries a significantly increased volume of emails.

  Specifically, Sashiko's comments are almost exclusively directed at the original contributor,
  who then submits a new version of the patch addressing those comments. But this process often
  repeats for several rounds: each new version triggers additional Sashiko feedback, leading to
  multiple intermediate patch revisions being posted to the main list. These intermediate versions
  are only relevant to the contributor and the bot—they do not require immediate human attention,
  yet they clutter the inboxes.

  In other words, the main list is currently used as a live iteration sandbox between Sashiko
  and the contributor, while human reviewers are forced to watch every step of this back‑and‑forth.
  That seems not necessary.

My suggestions

  To decouple the machine‑driven iteration loop from human‑driven review, I would like to propose a
  split workflow:

  1. Initial submission (v1): The contributor sends the first version of the patch series to the main
     list (mptcp@lists.linux.dev). Maintainers can quickly glance at it to filter out obviously invalid
     or low‑quality patches early.
  2. Bot‑driven iteration (v2, v3, …): For subsequent versions that only address Sashiko's feedback,
     the contributor posts those revisions to a separate, dedicated list (e.g., mptcp-sashiko@lists.linux.dev).
     Sashiko watches that list and provides its feedback there. The contributor can iterate as many
     times as needed without bothering the main list audience.
  3. Final polished version: Once Sashiko reports no meaningful comments (or only false‑positive warnings
     that the contributor has already handled), the contributor resends the final, cleaned‑up patch to
     the main list for human review.

The Benefits

  I believe both sides will benefit clearly if the sashiko process is mitigated:

  1. For reviewers/maintainers: Their main list inbox will only contain two types of patches—brand new
     submissions (v1) and "mature" patches that have already passed the bot's checks. This drastically
     reduces noise and allows them to focus their limited reviewing bandwidth on patches that are truly
     ready for human scrutiny.
  2. For contributors: They can iterate as fast and as often as they want in the sub‑list without feeling
     guilty about flooding the main list. They get a "safe sandbox" to polish the series until it meets
     the bot's criteria. When they finally post to the main list, the patch is already in a much better
     state, which should also speed up the human review process.

I want to stress that this is not a complaint or a demand. I fully respect the work that has gone into
Sashiko and the current process.

Looking forward to hearing everyone's thoughts.

Thanks
Gang

Re: [RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[gang.yan]

September 3, 2026 at 2:12 PM, gang.yan@linux.dev mailto:gang.yan@linux.dev  wrote:

> 
>  I believe both sides will benefit clearly if the sashiko process is mitigated:
> 
>  1. For reviewers/maintainers: Their main list inbox will only contain two types of patches—brand new
>  submissions (v1) and "mature" patches that have already passed the bot's checks. This drastically
>  reduces noise and allows them to focus their limited reviewing bandwidth on patches that are truly
>  ready for human scrutiny.
>  2. For contributors: They can iterate as fast and as often as they want in the sub‑list without feeling
>  guilty about flooding the main list. They get a "safe sandbox" to polish the series until it meets
>  the bot's criteria. When they finally post to the main list, the patch is already in a much better
>  state, which should also speed up the human review process.
> 

Having said that, I realize this might be an overdesign. If anyone else is bothered by the sashiko process
in a similar way, please leave messages under this thread, maybe we can find a lighter approach.

> I want to stress that this is not a complaint or a demand. I fully respect the work that has gone into
> Sashiko and the current process.
> 
> Looking forward to hearing everyone's thoughts.
> 
> Thanks
> Gang
>

Re: [RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[Matthieu Baerts]

Hi Gang,

On 03/09/2026 08:12, gang.yan@linux.dev wrote:
> Hi all,
> 
> Apologies for the extra email, and please don't take this as any criticism of the current workflow.

Thank you for your email, it's good to discuss that.

> I'm writing this email to see if anyone else in the community shares some confusion I have
> regarding the use of Sashiko—specifically, the multiple rounds of iteration and the large
> volume of emails generated on the main list.
> 
> Let me explain the problem more clearly.
> 
> The Problem
> 
>   Since Sashiko was introduced, it has greatly accelerated patch iteration for contributors.
>   However, from a human reviewer's perspective, the main mailing list (mptcp@lists.linux.dev)
>   now carries a significantly increased volume of emails.
> 
>   Specifically, Sashiko's comments are almost exclusively directed at the original contributor,
>   who then submits a new version of the patch addressing those comments. But this process often
>   repeats for several rounds: each new version triggers additional Sashiko feedback, leading to
>   multiple intermediate patch revisions being posted to the main list. These intermediate versions
>   are only relevant to the contributor and the bot—they do not require immediate human attention,
>   yet they clutter the inboxes.
> 
>   In other words, the main list is currently used as a live iteration sandbox between Sashiko
>   and the contributor, while human reviewers are forced to watch every step of this back‑and‑forth.
>   That seems not necessary.

I agree with you here, having to face many iterations is not good for
the reviewers, and not for the devs either.

> My suggestions
> 
>   To decouple the machine‑driven iteration loop from human‑driven review, I would like to propose a
>   split workflow:
> 
>   1. Initial submission (v1): The contributor sends the first version of the patch series to the main
>      list (mptcp@lists.linux.dev). Maintainers can quickly glance at it to filter out obviously invalid
>      or low‑quality patches early.
>   2. Bot‑driven iteration (v2, v3, …): For subsequent versions that only address Sashiko's feedback,
>      the contributor posts those revisions to a separate, dedicated list (e.g., mptcp-sashiko@lists.linux.dev).
>      Sashiko watches that list and provides its feedback there. The contributor can iterate as many
>      times as needed without bothering the main list audience.
>   3. Final polished version: Once Sashiko reports no meaningful comments (or only false‑positive warnings
>      that the contributor has already handled), the contributor resends the final, cleaned‑up patch to
>      the main list for human review.
But I cannot support your suggestion :)

Sashiko's usage has a cost: it is useful to have it to flag some
potential issues, so we want to continue having it for "legit" patches.
If its usage is "abused", then we might lose it for all patches.

At the last netdev, devs got told to run pre-checks locally, including
selftests but also AI reviews (when it is possible). Many companies are
already using LLMs, then their devs should also have their patches
tested by a local Sashiko. Sashiko can be easily executed locally, with
different models. The project's README explains how to install and use
it. In short, it is supposed to be easy: configure the model to use, run
"sashiko init", then "sashiko review". That's it. Or course, we cannot
force people to use it locally. Some refs:

 -
https://netdevconf.info/0x1A/docs/netdev-0x1a-paper49-talk-slides/Device%20driver%20workshop%20(2).pdf
 - https://github.com/linux-netdev/nipa/wiki/Running-Netdev-CI-tests-locally

Ideally, authors are expected to reply to Sashiko's emails and reviewers
can help checking if Sashiko is hallucinating (which still happen
frequently...) or is asking to fix issues that cannot happen in real
deployments. But the thing is that Sashiko can review and generate a lot
of text that humans -- especially busy reviewers -- might take time to
process. So the idea here is not to rush things, and ask questions when
something is unclear or look suspicious / wrong.

In conclusion, I don't think we want a "hidden" ML, but we do want to
reduce the traffic on the ML, and the recommended solution is to push
people validating their patches with the same tool (or closed to, if
possible) before any submissions. WDYT?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[gang.yan]

September 3, 2026 at 5:52 PM, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:

Hi, Matt

Thanks for your reply and detailed explanation.

> I agree with you here, having to face many iterations is not good for
> the reviewers, and not for the devs either.
> 
> > 
> > My suggestions
> >  
> >  To decouple the machine‑driven iteration loop from human‑driven review, I would like to propose a
> >  split workflow:
> >  
> >  1. Initial submission (v1): The contributor sends the first version of the patch series to the main
> >  list (mptcp@lists.linux.dev). Maintainers can quickly glance at it to filter out obviously invalid
> >  or low‑quality patches early.
> >  2. Bot‑driven iteration (v2, v3, …): For subsequent versions that only address Sashiko's feedback,
> >  the contributor posts those revisions to a separate, dedicated list (e.g., mptcp-sashiko@lists.linux.dev).
> >  Sashiko watches that list and provides its feedback there. The contributor can iterate as many
> >  times as needed without bothering the main list audience.
> >  3. Final polished version: Once Sashiko reports no meaningful comments (or only false‑positive warnings
> >  that the contributor has already handled), the contributor resends the final, cleaned‑up patch to
> >  the main list for human review.
> > 
> But I cannot support your suggestion :)
> 
> Sashiko's usage has a cost: it is useful to have it to flag some
> potential issues, so we want to continue having it for "legit" patches.
> If its usage is "abused", then we might lose it for all patches.
> 
> At the last netdev, devs got told to run pre-checks locally, including
> selftests but also AI reviews (when it is possible). Many companies are
> already using LLMs, then their devs should also have their patches
> tested by a local Sashiko. Sashiko can be easily executed locally, with
> different models. The project's README explains how to install and use
> it. In short, it is supposed to be easy: configure the model to use, run
> "sashiko init", then "sashiko review". That's it. Or course, we cannot
> force people to use it locally. Some refs:
> 
>  -
> https://netdevconf.info/0x1A/docs/netdev-0x1a-paper49-talk-slides/Device%20driver%20workshop%20(2).pdf
>  - https://github.com/linux-netdev/nipa/wiki/Running-Netdev-CI-tests-locally
> 
> Ideally, authors are expected to reply to Sashiko's emails and reviewers
> can help checking if Sashiko is hallucinating (which still happen
> frequently...) or is asking to fix issues that cannot happen in real
> deployments. But the thing is that Sashiko can review and generate a lot
> of text that humans -- especially busy reviewers -- might take time to
> process. So the idea here is not to rush things, and ask questions when
> something is unclear or look suspicious / wrong.
> 
> In conclusion, I don't think we want a "hidden" ML, but we do want to
> reduce the traffic on the ML, and the recommended solution is to push
> people validating their patches with the same tool (or closed to, if
> possible) before any submissions. WDYT?

I now see that my idea was probably too naive/overly simplistic :)

I have tried deploying Sashiko locally and noticed that different models can
produce quite different review outputs. For now, I am willing to defer to the
community's existing practice.

Thanks again for your time.

Cheers,
Gang

> 
> Cheers,
> Matt
> -- 
> Sponsored by the NGI0 Core fund.
>

Re: [RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[Matthieu Baerts]

Hi Gang,

On 04/09/2026 09:25, gang.yan@linux.dev wrote:
> September 3, 2026 at 5:52 PM, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:

(...)

>> In conclusion, I don't think we want a "hidden" ML, but we do want to
>> reduce the traffic on the ML, and the recommended solution is to push
>> people validating their patches with the same tool (or closed to, if
>> possible) before any submissions. WDYT?
> 
> I now see that my idea was probably too naive/overly simplistic :)
> 
> I have tried deploying Sashiko locally

Thank you for having done that.

> and noticed that different models can produce quite different review outputs.

Yes indeed, and from what I understood, even the same model can produce
different results. But I think that's fine, and I hope various models
out there can at least spot "simple" / "important" issues. So even if
the model(s) you can access to is/are "not as precise/picky" as the
Google one, that's still good to have a such pre-checks being done to
reduce the number of iterations.

Note that Clashiko is running multiple models and doing cross reviews.
In theory, that sounds good to have less false positives (but then, it
seems to be very/too picky as well...). So at the end, it seems like a
good thing to have access to various models to cross checks the reviews.

Cheers,
Matt

Re: [RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[Shardul Bankar]

Hi Matt, Gang,

On 04/09/2026 12:32, Matthieu Baerts wrote:
> So at the end, it seems like a good thing to have access to various
> models to cross checks the reviews.

Agreed, and that is where I ran into something worth passing on. If the
plan is for people to run reviews locally, and more than one model at
that, then what a local run costs decides whether anyone actually keeps
doing it.

I ran Sashiko locally against my Claude subscription, using the Claude
Code CLI provider rather than an API key. One patch took about 45
minutes and consumed essentially a whole usage window. That window is
five hours, so it works out at roughly one patch per window on that
setup, which was enough to have me scheduling runs around the reset
rather than just running them when I wanted a review. That timing was in
August, on a build from before the declarative workflow engine landed,
so I cannot say the 45 minutes still holds. What has not changed is the
shape of it: the CLI provider still starts a separate claude process per
stage, with no session carried between them, so the context is built and
sent again for each one.

The part I did not know at the time is that there are two quite
different things here. "sashiko init" then "sashiko review" runs the
full staged pipeline, one process per stage, and that is the expensive
one. The Sashiko repository also ships, in the prompt bundle it vendors,
a /kreview command that runs the review as a single Claude Code session,
so the context is read once instead of once per stage.

/kreview is not mentioned in Sashiko's README, its maintainers guide, or
anything under docs/. It is documented only in
third_party/prompts/README.md, inside the vendored copy of the review
prompts, with the command itself in
third_party/prompts/kernel/slash-commands/kreview.md. So anyone
following the setup instructions gets the expensive path and has no
particular reason to learn the other one exists. That seems worth fixing
if the goal is more people running checks before they post.

A few of the things that make a local run costlier than it needs to be
look fixable, and I have sent patches for them to the Sashiko project
rather than describe them here, since that is where they belong. One is
worth a line because of where it does and does not apply: Sashiko can
cache model responses so a repeated request is answered from disk rather
than sent again, but that setting has no effect on the local path, so
retrying a failed run pays for everything a second time. The reviews you
see arriving on this list are unaffected, since the daemon that posts
them does use the cache.

One other thing, unrelated to cost and possibly of wider interest. Of
the findings Sashiko has published for this list, the ones it marks as
pre-existing are graded higher than the ones it attributes to the patch
under review. Roughly 95 percent of the pre-existing ones are High or
Critical and not one is Low, against roughly half for the findings
attributed to the patch. I had been treating "this was already broken"
as a reason to downgrade, and that is not how the tool treats it. The
reasoning holds up, since a pre-existing bug is live in the shipping
kernel while one introduced by a patch under review will most likely be
caught before it merges.

Gang, you mentioned deploying Sashiko locally. Did you see anything like
the same cost, and what were you running it against? If this turns out
to be particular to a fixed-quota subscription, I would rather find that
out than have people avoid running reviews locally over a cost that does
not apply to them.

Thanks,
Shardul

Re: [RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[Matthieu Baerts]

Hi Shardul,

Thank you for sharing this feedback!

On 07/09/2026 14:57, Shardul Bankar wrote:
> On 04/09/2026 12:32, Matthieu Baerts wrote:
>> So at the end, it seems like a good thing to have access to various
>> models to cross checks the reviews.
> 
> Agreed, and that is where I ran into something worth passing on. If the
> plan is for people to run reviews locally, and more than one model at
> that, then what a local run costs decides whether anyone actually keeps
> doing it.

Just to avoid confusions, even if running multiple models *should* be
better (and/or having one cross-reviewing the comment from another one),
running one is already good, but only for those who are able to, i.e.
companies already using them. And that's what netdev maintainers expect,
so it somehow applies to MPTCP as well. I'm clearly not going to enforce
it, especially to individuals (like me) or people who don't want to use
for various reasons. The idea is "if your company is using LLM, then use
it to pre-review patches to save cycles".

> I ran Sashiko locally against my Claude subscription, using the Claude
> Code CLI provider rather than an API key. One patch took about 45
> minutes and consumed essentially a whole usage window. That window is
> five hours, so it works out at roughly one patch per window on that
> setup, which was enough to have me scheduling runs around the reset
> rather than just running them when I wanted a review. That timing was in
> August, on a build from before the declarative workflow engine landed,
> so I cannot say the 45 minutes still holds. What has not changed is the
> shape of it: the CLI provider still starts a separate claude process per
> stage, with no session carried between them, so the context is built and
> sent again for each one.
> 
> The part I did not know at the time is that there are two quite
> different things here. "sashiko init" then "sashiko review" runs the
> full staged pipeline, one process per stage, and that is the expensive
> one. The Sashiko repository also ships, in the prompt bundle it vendors,
> a /kreview command that runs the review as a single Claude Code session,
> so the context is read once instead of once per stage.
> 
> /kreview is not mentioned in Sashiko's README, its maintainers guide, or
> anything under docs/. It is documented only in
> third_party/prompts/README.md, inside the vendored copy of the review
> prompts, with the command itself in
> third_party/prompts/kernel/slash-commands/kreview.md. So anyone
> following the setup instructions gets the expensive path and has no
> particular reason to learn the other one exists. That seems worth fixing
> if the goal is more people running checks before they post.

Good idea!

(I didn't know it could take that long + the window time)

> A few of the things that make a local run costlier than it needs to be
> look fixable, and I have sent patches for them to the Sashiko project
> rather than describe them here, since that is where they belong. One is
> worth a line because of where it does and does not apply: Sashiko can
> cache model responses so a repeated request is answered from disk rather
> than sent again, but that setting has no effect on the local path, so
> retrying a failed run pays for everything a second time. The reviews you
> see arriving on this list are unaffected, since the daemon that posts
> them does use the cache.

I do wonder how people use it. Maybe many companies have deployed their
own Sashiko and local reviews are not common? (but I doubt that)

I would also not be surprised that many people don't care about the
cost, and if they use an internal ranking, it is possibly even better
without cache...

> One other thing, unrelated to cost and possibly of wider interest. Of
> the findings Sashiko has published for this list, the ones it marks as
> pre-existing are graded higher than the ones it attributes to the patch
> under review. Roughly 95 percent of the pre-existing ones are High or
> Critical and not one is Low, against roughly half for the findings
> attributed to the patch. I had been treating "this was already broken"
> as a reason to downgrade, and that is not how the tool treats it. The
> reasoning holds up, since a pre-existing bug is live in the shipping
> kernel while one introduced by a patch under review will most likely be
> caught before it merges.
Note that pre-existing issues don't always need to be fixed as part of a
series adding a new feature. A message about that in the commit message,
in the commit note or in reply to Sashiko's email. If the issue is real,
the impact has not changed with the modification, and the fix is not
simple, it is enough to create a new ticket on GitHub and look (or
someone else) at it later.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[gang.yan]

> 
> Gang, you mentioned deploying Sashiko locally. Did you see anything like
> the same cost, and what were you running it against? If this turns out
> to be particular to a fixed-quota subscription, I would rather find that
> out than have people avoid running reviews locally over a cost that does
> not apply to them.
> 

Hi Shardul,

Thanks for your reply.

Sorry for the delayed reply; work has kept me busy lately so I haven’t had much
time to check emails. Please also excuse my English — I might have caused some
confusion earlier. I'm using the API key and noticed the cost.

I’d like to share my experience with an API-key Sashiko deployment, which may help
folks on this list use Sashiko at lower cost.

I run Sashiko using Minimax as the LLM. Minimax offers a monthly subscription plan
and is quite affordable. (I submitted a small PR to Sashiko to fix some issues
I encountered while using it.)

One observation: reviewing large patch series via the web interface can burn through
the 5-hour quota very quickly. In contrast, using `sashiko-cli` from the command line
seems to cut token consumption significantly, this is from my practical testing.

I also tried GLM, which is another fixed-quota subscription model and relatively
more expensive. While its quality is not as good as Gemini or Opus, it still works
well for local code iteration.

I’m still relatively new to working with AI tools. If you have any approaches to save tokens,
would you mind sharing them on this thread?

Thanks
Gang

> Thanks,
> Shardul
>

Re: [RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[Matthieu Baerts]

Hi Gang, Shardul,

On 10/09/2026 13:08, gang.yan@linux.dev wrote:
>>
>> Gang, you mentioned deploying Sashiko locally. Did you see anything like
>> the same cost, and what were you running it against? If this turns out
>> to be particular to a fixed-quota subscription, I would rather find that
>> out than have people avoid running reviews locally over a cost that does
>> not apply to them.
>>
> 
> Hi Shardul,
> 
> Thanks for your reply.
> 
> Sorry for the delayed reply; work has kept me busy lately so I haven’t had much
> time to check emails. Please also excuse my English — I might have caused some
> confusion earlier. I'm using the API key and noticed the cost.
> 
> I’d like to share my experience with an API-key Sashiko deployment, which may help
> folks on this list use Sashiko at lower cost.
> 
> I run Sashiko using Minimax as the LLM. Minimax offers a monthly subscription plan
> and is quite affordable. (I submitted a small PR to Sashiko to fix some issues
> I encountered while using it.)
> 
> One observation: reviewing large patch series via the web interface can burn through
> the 5-hour quota very quickly. In contrast, using `sashiko-cli` from the command line
> seems to cut token consumption significantly, this is from my practical testing.
> 
> I also tried GLM, which is another fixed-quota subscription model and relatively
> more expensive. While its quality is not as good as Gemini or Opus, it still works
> well for local code iteration.
> 
> I’m still relatively new to working with AI tools. If you have any approaches to save tokens,
> would you mind sharing them on this thread?

Did you install Semcode [1]?

I remember that this tool was recommended to people using Chris Mason's
Review Prompts [2], and Sashiko use them [3].

(I tried to use Semcode manually, but I didn't get along with it, maybe
I should retry, or maybe it is mostly made for agents?)

It looks like this tool can save tokens (don't ask me how/how much) with
the review prompt [2]. Maybe with Sashiko as well? (If yes, Sashiko's
README should mention it as well.)

One last thing, Shardul, I noticed the "/kreview" you mentioned is
something from the review prompts [2]. Perhaps it is not running
everything from Sashiko, just a part of it?

[1] https://github.com/facebookexperimental/semcode
[2] https://github.com/masoncl/review-prompts
[3] https://github.com/sashiko-dev/sashiko#prompts

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.