Re: fixing sashiko failure to apply (was Re: [PATCH v5 00/16] mm/rmap: index MAP_PRIVATE file-backed folios by anonymous pgoff)

[Roman Gushchin <roman.gushchin@linux.dev>]

> On Aug 14, 2026, at 11:30 AM, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> 
> [ trim cc list ]
> 
> +cc Roman
> 
>> On Fri, Aug 14, 2026 at 02:13:51AM -0700, Matthew Brost wrote:
>>> On Fri, Aug 14, 2026 at 10:01:19AM +0100, Lorenzo Stoakes (ARM) wrote:
>>> On Thu, Aug 13, 2026 at 11:53:46AM -0700, Andrew Morton wrote:
>>>> You'll be mortified to hear that Sashiko wasn't able to find anything
>>>> to which to apply this.
>>> 
>>> :))
>>> 
>>> Well, when it's right it's useful, when it's wrong or suggesting unrelated
>>> what-nots it's less useful :>)
>>> 
>> 
>> Questioning your assumptions is useful, even when they turn out to be wrong.
>> Show more lines
>> 
>>> I do locally put things through claude + Chris Mason's prompts a lot, I
>>> don't always invoke local sashiko as it's very slow and token-heavy or has
>>> been so far, but am planning to do that more also in future.
>>> 
>> 
>> Yes, it's kind of odd that Sashiko burns more tokens than a full day of
>> breakfast, lunch, and dinner service. Running Sashiko is a bottleneck in
>> my workflow, so I'll defer to others on this list.
> 
> Yup, not sure if there are recommended configs for something saner :)
> 
> Maybe Roman has some advice on that?

Sorry, no magic way to save tokens without hurting the quality. But I am curious what are your numbers?
Can be model-dependent too. In prod on average it burns 3-4M tokens per patch with Gemini 3.1 Pro, 
but maybe mm patches are more complex than average, Idk.

One option is to run only some discovery stages (—stages), but this unlikely will save you that much.
I’d say use a cheaper and faster model for the development, but it has it’s downsides too.

If you have an example of a patch(set) which is particularly token-hungry, I can take a look.
> 
>> 
>>>> 
>>>> Sashiko can be guided with a base-commit: tag but I'm not sure how to
>>>> tell it what tree/branch to try, or even if that's necessary.  Perhaps
>>>> someone can figure this out sometime.
>>> 
>>> b4 gives a base commit, but I think because the trees are rebased it ends
>>> up being the incorrect one.
>>> 
>>> Not sure what the solution is!
>>> 
>> 
>> We have seen this on the Xe list (our list is based on drm-tip),
>> typically with cross-subsystem patches. Some cross-subsystem patches
>> apply and run correctly, while others do not but public CI flows run
>> based on drm-tip. I do not have a bisect or a clear understanding of
>> what works and what doesn't, but I think it would be very useful if the
>> community could better understand the root cause.
> 
> As Mike said, mm-unstable/mm-new is heavily rebased and also carries the old
> version of the series before the new one is applied, so it's super unclear what
> the base commit should be there.
> 
> But in general, I wonder if it's possible that we could tell sashiko
> after-the-fact what base commit to look at once the series is in, or re-trigger
> it somehow once it's in-tree?
> 
> Roman - any suggestions on what we could do to help sashiko find things?
> 
> (Once mm-next is in place everything with change again, but can address that
> then :)

I can implement any reasonable logic here, the problem is that my understanding is
the current mm process is a bit vague here. Which likely will be also an issue for the mm ci.
I’ll merge a support for b4-like dependencies specification soon.

Re re-starting with manual selection it’s on my todo list, but maybe a bit lfurther away, as it requires
an authorization, etc.

Thanks