From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.3 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794386205; b=qhiiZpuF50AuaP0g2x9BF1iCO7/DG87NoU6afwS9idGH0meaqK6ZKYdVuZjIFZufaHND Dp/rqNLkqLv60h7ue7Ooc19oBblMOESKa79TS1DMSFC6eBSPrC4PFg1TESIyy1FBUebA2 uVdo4r+ZuZJ22lM3VEy+SjxEBAfCamSoUERgilCuOyT5WUGJkuD46TED2s/eoeItY83AW 7Rc08k90qZZSce7D3hHj9ceOkhOKKt9jRN8Z1i22Ep004k/V/USVX3gXoClvSf3xsX+JI EFCpNawL7XUZoHSUTsDWtqWUhDyI61nThbPjg9dOfLuz7YUgeVVb/18yfxlJXWhm2cQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794386205; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:From:To:Cc:Subject:Date:Message-Id: X-Mailer:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding; bh=5xxIaNpSszE+yFqAyJ2Rb4E+WWq4DFNGesE5ueGQKRM=; b=ZK16hqDJie4zwWlM3C7hAgfn4BH204FKWijaMwbQ+n6rDEiLZgSHHGTVmZJEtlTL7C5a ISDTlJLQhlnbO6XTRQF4vcTPYCT4UU+4Fu0IUBnNjm+jX2fwGkc48QQMhxj7XM6eKK1oi R5/1a/lxts5/Sic3XXJKL9p+sNRYkUEv2kk+U4afmq+aYO6ejZqdHV3dU37kWrH1Oi90O q43W16e+74iPxdbR3nNdYfeCj0y6c+0I6H9o0jhxn2y0t//WVZygl65E60A0WMJboFRpy W4hVAG1rsDOtceb0fTyKS7x1XYniW6SElGT9dWPHayFW9VdJVEmEzAN9+Matz8hWMDQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=SaMHMNHQ; arc=none smtp.remote-ip=91.218.175.3 Received: from mta0.migadu.com (out-3.mta0.migadu.com [91.218.175.3]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA340606A320 for ; Wed, 11 Nov 2026 08:36:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org EA340606A320 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=SaMHMNHQ X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=k+uY4WofA8Sf868/Blel8K6cJ0//MXYQbHMDv5vxkh4=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1794386203; v=1; x=1794991003; b=SaMHMNHQF0bVSsgGyG9oT0DkpM1ywpR6EXqL//INxGPOfDNUgSWKXvJ8dHZhIDWWSLW/DGfq TAB4ekSEwqwsG7nVlZS/UJcg9ykxlFtntfeUSsPgRW2/al8mktHy4V1HDZqg7+swoTzbSQ63EzD Fnn9QzWQv/bDmtJU+9U/QIA0= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta11.migadu.com with ESMTPS id a175cba2f5d7ab7a; Wed, 11 Nov 2026 08:36:43 +0000 X-Mizu-Trace-ID: a175cba2f5d7ab7a X-Migadu-Flow: FLOW_OUT From: "Xu Xin (vivo)" 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 Message-Id: <20261111083632.57199-1-xu.xin@linux.dev> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > 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