From: Andrew Morton <akpm@linux-foundation.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: "Lorenzo Stoakes (Oracle)" <ljs@kernel.org>,
Vernon Yang <vernon2gm@gmail.com>,
Wei Yang <richard.weiyang@gmail.com>,
lorenzo.stoakes@oracle.com, ziy@nvidia.com, dev.jain@arm.com,
baohua@kernel.org, lance.yang@linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Vernon Yang <yanglincheng@kylinos.cn>
Subject: Re: [PATCH mm-new v8 2/4] mm: khugepaged: refine scan progress number
Date: Wed, 25 Mar 2026 09:17:35 -0700 [thread overview]
Message-ID: <20260325091735.bf440358cf83c5d0369e0674@linux-foundation.org> (raw)
In-Reply-To: <0437ad42-612e-461f-906d-6757eb19a8de@kernel.org>
On Wed, 25 Mar 2026 16:22:55 +0100 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> >
> > Really larger stuff should be resent I think, esp. if there's multiple
> > fixes in the series.
> >
> > A reply with the same-patch-but-with-fix-applied would definitely be
> > useful!
>
> Right, for completeness, this is what we had in an off-list thread:
>
> "
> Not sure if that's a problem for others, but I got the feeling that this
> escalated a bit lately.
>
> I know, that we prefer fixups to sort out smaller stuff. So far so good.
> In the last time there were some series where I was seriously completely
> lost which state of the patches would go upstream, or what I should even
> review, because there were just fixups over fixups.
>
> Fixups are nice, but for someone reviewing a series, too many fixups
> (either as inline patch or even worse, as independent patches) just
> causes a mess.
>
> It also gives the impression of "this is mostly done, so don't waste
> your time reviewing it anymore." --- "just the finishing touches" ---
> "don't jump in late and cause trouble".
> "
hm OK, so what to do. We're OK with teeny -fixes but anything more
substantial we ask for a full resend and I do the heres-what-changed
reply?
I presently don't fold the -fixes until the very last moment. Could do
that much earlier if it helps anything? Possibly useful to people who
are looking at the series in the mm.git tree.
next prev parent reply other threads:[~2026-03-25 16:17 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-21 9:39 [PATCH mm-new v8 0/4] Improve khugepaged scan logic Vernon Yang
2026-02-21 9:39 ` [PATCH mm-new v8 1/4] mm: khugepaged: add trace_mm_khugepaged_scan event Vernon Yang
2026-03-25 14:06 ` Lorenzo Stoakes (Oracle)
2026-02-21 9:39 ` [PATCH mm-new v8 2/4] mm: khugepaged: refine scan progress number Vernon Yang
2026-02-24 3:52 ` Wei Yang
2026-02-25 14:25 ` Vernon Yang
2026-02-25 14:29 ` David Hildenbrand (Arm)
2026-02-26 14:31 ` Vernon Yang
2026-02-26 15:45 ` David Hildenbrand (Arm)
2026-02-26 17:15 ` Vernon Yang
2026-03-25 14:10 ` Lorenzo Stoakes (Oracle)
2026-03-25 14:22 ` Lorenzo Stoakes (Oracle)
2026-03-25 15:09 ` Andrew Morton
2026-03-25 15:17 ` David Hildenbrand (Arm)
2026-03-25 15:20 ` Lorenzo Stoakes (Oracle)
2026-03-25 15:22 ` David Hildenbrand (Arm)
2026-03-25 16:17 ` Andrew Morton [this message]
2026-03-25 16:26 ` Lorenzo Stoakes (Oracle)
2026-03-25 18:36 ` Andrew Morton
2026-03-25 18:53 ` Lorenzo Stoakes (Oracle)
2026-03-25 19:15 ` Andrew Morton
2026-03-25 20:03 ` Lorenzo Stoakes (Oracle)
2026-03-25 20:16 ` David Hildenbrand (Arm)
2026-03-25 20:49 ` Andrew Morton
2026-03-25 17:00 ` Vernon Yang
2026-03-25 17:08 ` Lorenzo Stoakes (Oracle)
2026-03-25 18:59 ` Andrew Morton
2026-03-25 19:04 ` Lorenzo Stoakes (Oracle)
2026-03-26 1:59 ` Vernon Yang
2026-03-26 8:03 ` Lorenzo Stoakes (Oracle)
2026-02-21 9:39 ` [PATCH mm-new v8 3/4] mm: add folio_test_lazyfree helper Vernon Yang
2026-02-21 9:39 ` [PATCH mm-new v8 4/4] mm: khugepaged: skip lazy-free folios Vernon Yang
2026-02-21 10:27 ` Barry Song
2026-02-21 13:38 ` Vernon Yang
2026-02-23 13:16 ` David Hildenbrand (Arm)
2026-02-23 20:08 ` Barry Song
2026-02-24 10:10 ` David Hildenbrand (Arm)
2026-02-23 20:10 ` Barry Song
2026-02-26 7:55 ` Vernon Yang
2026-03-16 19:41 ` Andrew Morton
2026-03-17 2:16 ` Vernon Yang
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=20260325091735.bf440358cf83c5d0369e0674@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=richard.weiyang@gmail.com \
--cc=vernon2gm@gmail.com \
--cc=yanglincheng@kylinos.cn \
--cc=ziy@nvidia.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox