All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Xu Xin (vivo)" <xu.xin@linux.dev>
To: david@kernel.org
Cc: ljs@kernel.org, akpm@linux-foundation.org,
	chengming.zhou@linux.dev, link@vivo.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	tujinjiang@huawei.com, xiao.wang@vivo.com, xu.xin@linux.dev
Subject: Re: [PATCH 2/4] ksm: skip rmap_item allocation for non-zero pages under only_merge_zero_pages
Date: Wed, 11 Nov 2026 16:36:32 +0800	[thread overview]
Message-ID: <20261111083632.57199-1-xu.xin@linux.dev> (raw)
In-Reply-To: <avMKhCLDv-ybpmIZ@gremlin>

> On Tue, Nov 10, 2026 at 07:22:06PM +0800, Xu Xin (vivo) wrote:
> > On Tue, Nov 10, 2026 at 10:05:20AM +0000, Lorenzo Stoakes (ARM) wrote:
> > > On Tue, Nov 10, 2026 at 03:44:49PM +0800, Xu Xin (vivo) wrote:
> > > >
> > > > A page that is zero now but is written before cmp_and_merge_page() runs
> > > > is still handled correctly, because the checksum-based decision in
> > > > cmp_and_merge_page() (added by the previous patch) is the authoritative
> > > > one.
> > > >
> > >
> > > Please re-write this in your own words.
> > >
> > > It seems very LLM generated, LLMs are _terrible_ at writing commit messages
> > > and commits, please re-write all of that.
> >
> > Indeed, the description was generated by LLM, but I thought that was clear enough
> > to present what this patch do and why. Aparrently, you don't like that style, I'll
> > rewrite that by handd.
> 
> In general we never want LLM-generated commit messages/comments.
> 
> I do however obviously appreciate and empathise with using it to assist
> non-native speakers. So that's fine, but ideally you would write it up yourself
> and then have the LLM do simply a polishing layer, keeping the length as small
> as possible, which should give us the best of both worlds. Thanks :)
> 
> >
> > The goal is only to avoid rmap_item allocation for pages that can never merge
> > under only_merge_zero_pages. The implementation is simple.
> >
> > I'll send a v3 with those changes.
> 
> Well let's wait on David's POV on this series for this cycle before a respin
> first thanks!

Thanks Lorenzo, makes sense.

Hi David,

What are your thoughts on targeting this series for this cycle? I understand
you have a lot on your plate having just taken over mm/core.git and are
focusing on bugfixes right now, so I'm fine with deferring this to the next
cycle even though the implementation itself is fairly straightforward.

Whenever it's a good time for sending a v3, I'll make sure to address Lorenzo's
feedback by rewriting the commit messages and comments, and simplifying
scan_get_next_rmap_item() as much as possible.

Thanks,
Xu


  reply	other threads:[~2026-11-11  8:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10  7:43 [PATCH v2 0/4] KSM: introduce only_merge_zero_pages Xu Xin (vivo)
2026-11-10  7:44 ` [PATCH 1/4] ksm: add only_merge_zero_pages to merge only empty anonymous pages Xu Xin (vivo)
2026-11-10  7:44   ` [PATCH 2/4] ksm: skip rmap_item allocation for non-zero pages under only_merge_zero_pages Xu Xin (vivo)
2026-11-10 10:05     ` Lorenzo Stoakes (ARM)
2026-11-10 11:22       ` Xu Xin (vivo)
2026-11-10 12:42         ` Lorenzo Stoakes (ARM)
2026-11-11  8:36           ` Xu Xin (vivo) [this message]
2026-11-11  8:48             ` Lorenzo Stoakes (ARM)
2026-11-11  9:04             ` David Hildenbrand (Arm)
2026-11-11  9:08     ` David Hildenbrand (Arm)
2026-11-11  9:36       ` Xu Xin (vivo)
2026-11-10  7:44   ` [PATCH 3/4] selftests/ksm: consolidate ksm_stat readers into ksm_get_self_stat() Xu Xin (vivo)
2026-11-10  7:44   ` [PATCH 4/4] selftests/ksm: add test for only_merge_zero_pages Xu Xin (vivo)
2026-11-11  9:10   ` [PATCH 1/4] ksm: add only_merge_zero_pages to merge only empty anonymous pages David Hildenbrand (Arm)
2026-11-10 10:08 ` [PATCH v2 0/4] KSM: introduce only_merge_zero_pages Lorenzo Stoakes (ARM)
2026-11-10 11:34   ` Xu Xin (vivo)

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=20261111083632.57199-1-xu.xin@linux.dev \
    --to=xu.xin@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=david@kernel.org \
    --cc=link@vivo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=tujinjiang@huawei.com \
    --cc=xiao.wang@vivo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.