Re: [PATCH mm-new v8 2/4] mm: khugepaged: refine scan progress number

["David Hildenbrand (Arm)" <david@kernel.org>]

On 3/25/26 21:03, Lorenzo Stoakes (Oracle) wrote:
> On Wed, Mar 25, 2026 at 12:15:49PM -0700, Andrew Morton wrote:
>> On Wed, 25 Mar 2026 18:53:40 +0000 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
>>
>>>
>>> I mean instead of having a separate commit for the fix, put that fix into the
>>> patch before it and denote it with a footer as you put above.
>>>
>>> I guess that translates to what you do when you rebase and fold the fixes into
>>> commits as you do now anyway.
>>>
>>> I don't see any reason not to do that right away, as really it's good to see the
>>> combined change in one go for all practical purposes (if I resend, I'll be
>>> combining work, if I can grab it from the tree and avoid a git rebase -i all the
>>> better).
>>
>> OK.  So what have we concluded here?
>>
>> Is it: if I get a -fix, I add that in the usual way, then temporarily
>> fold it into the base patch and mail the result out for fyi.  Then
>> after <period> I permanently fold the fix into the base and add the
>> footer?
>>
>> If so, what's <period>?
> 
> To me it feels like that should be 0, just squash it in right away, since the
> trees are being rebased constantly right?
> 
> And that means the tree contains exactly what it would if the series were
> re-sent.
> 
> David, what do you think?

How often was it helpful that a fixup patch would stay separate? I would
assume "not often". :)

-- 
Cheers,

David