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

On Fri, Aug 14, 2026 at 03:53:36PM +0200, Roman Gushchin wrote:
> >> 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.

Oh well damn, no 3-4M per patch sounds about right actually. I guess that just
is what it is then!

> >
> >>
> >>>>
> >>>> 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.

Yeah I suspect things might be tricky with mm given the rebases honestly.

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

Yeah that's the fly in the ointment I guess for many things like giving instant
feedback on accuracy, well you want to make sure the person giving it is who you
think they are :)

Probably an email -> author with magic link or something but thinking through
how to avoid abuse/spam/rate limiting everything etc. is surely all a pain :)

Good to hear it's the TODO list though!

>
> Thanks

--
Cheers, Lorenzo