From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42CAAC433F5 for ; Mon, 10 Oct 2022 13:42:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8DB476B0075; Mon, 10 Oct 2022 09:42:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 863036B0078; Mon, 10 Oct 2022 09:42:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68E8B6B007B; Mon, 10 Oct 2022 09:42:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 50B596B0075 for ; Mon, 10 Oct 2022 09:42:58 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1747F1C668B for ; Mon, 10 Oct 2022 13:42:58 +0000 (UTC) X-FDA: 80005155636.05.54069A4 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf04.hostedemail.com (Postfix) with ESMTP id A2EB440024 for ; Mon, 10 Oct 2022 13:42:56 +0000 (UTC) Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29ACLwCk025189; Mon, 10 Oct 2022 13:42:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=pp1; bh=MpV3+fZa1b3ZgpHkZvz4mAxRXNRh68Ci9DFQYQ7FNGw=; b=GwW7jRWH1AsS1CdOxzewbls2Nxy82dtaJEhC8hENTlW7URRdNoLfsbuVx0wtm+2TEiv+ QwCauHTxx2SSSDbhLIJDdUu024L1OxdXuLMxFDn7rkcLqKzd1xDqRpqTOYha8W5mXO8c 6pEiLXx5Te7eEjCkPjr9zv4psoarT65uXJZ3A5EDfKtlmckPMcTqCdRB7S6LTn3XDWl2 tsLt88UvQeeqF58T0MTI90fRHpeHM46bvfKGujb5DYd1oilLZr+7Z4mgW8w0DbISYHV/ TL/Rgiyy499ixWU0geFlntEcEE5w57b+wlXQVuJaT6r1hitUxsLMadCT9hEEJ32GhqC5 dw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3k3k8snwau-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Oct 2022 13:42:55 +0000 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 29ADIPXk028179; Mon, 10 Oct 2022 13:42:55 GMT Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3k3k8snw9y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Oct 2022 13:42:54 +0000 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 29ADcON2021603; Mon, 10 Oct 2022 13:42:53 GMT Received: from b06avi18878370.portsmouth.uk.ibm.com (b06avi18878370.portsmouth.uk.ibm.com [9.149.26.194]) by ppma03fra.de.ibm.com with ESMTP id 3k30u9a42u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Oct 2022 13:42:52 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06avi18878370.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 29ADhLsn53281206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 Oct 2022 13:43:21 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93F50A4054; Mon, 10 Oct 2022 13:42:50 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 44149A4060; Mon, 10 Oct 2022 13:42:50 +0000 (GMT) Received: from p-imbrenda (unknown [9.152.224.242]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 10 Oct 2022 13:42:50 +0000 (GMT) Date: Mon, 10 Oct 2022 15:42:48 +0200 From: Claudio Imbrenda To: xu xin Cc: akpm@linux-foundation.org, david@redhat.com, jiang.xuexin@zte.com.cn, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ran.xiaokai@zte.com.cn, xu.xin16@zte.com.cn, yang.yang29@zte.com.cn Subject: Re: [PATCH v2 0/5] ksm: support tracking KSM-placed zero-pages Message-ID: <20221010154248.1ee86294@p-imbrenda> In-Reply-To: <20221010120834.318840-1-xu.xin16@zte.com.cn> References: <20221010112413.219dc989@p-imbrenda> <20221010120834.318840-1-xu.xin16@zte.com.cn> Organization: IBM X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: fvRHA324ng9aHwHN3Nr-NrkmzC7sMAn7 X-Proofpoint-GUID: ZhsBsQbPyOeIL9gs8xS2cD-bUmD7byYQ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-10-10_08,2022-10-10_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 bulkscore=0 phishscore=0 impostorscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2210100081 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665409377; a=rsa-sha256; cv=none; b=yBwl/UnnPth3cjjKhajl/uxohYLW2gb2ou0OJlCmabsYUPjs1Y7Gujgf2hyCCF9YJBh3sv mkAODl7MAEckNu6Se2jrkqFGys0pyEEYkdBKXneJK1WWAUo1tWEsZL4uOeA6LZ9oDy6fRt VmgvbPP4IVt89hJ9dZDalUHsOjoCwAY= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=GwW7jRWH; spf=pass (imf04.hostedemail.com: domain of imbrenda@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=imbrenda@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665409377; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MpV3+fZa1b3ZgpHkZvz4mAxRXNRh68Ci9DFQYQ7FNGw=; b=l4AuZ1tZ/ljh12+ef5S0SCnQCm2J3kT8JQvA8y25CP3I72lsDcfXpx4b93+ysOFqXZOqUV JLl3k8fVCpt9qgb0aTpg3dbRK4bwIdDr2cFW8uk24qoypygEA2pXwXs5BydVm081OTnDp7 SbXZIcmWlOOswv4RyBCTXZ7lIkAjXxM= Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=GwW7jRWH; spf=pass (imf04.hostedemail.com: domain of imbrenda@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=imbrenda@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com X-Stat-Signature: e5mqcrmujqa8fmngsrdmwm3bz7ct19fh X-Rspamd-Queue-Id: A2EB440024 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1665409376-478369 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 10 Oct 2022 12:08:34 +0000 xu xin wrote: > Hello, Thanks for your reply. > > > > >why are you trying so hard to fix something that is not broken? > > Actually, it breaks the definition of unmerge, though it's usually not a big > problem. > > > >can't you just avoid using use_zero_pages? > > use_zero_pages is good, not just because of cache colouring as described in doc, > but also because use_zero_pages can accelerate merging empty pages when there > are plenty of empty pages (full of zeros) as the time of page-by-page comparision > (unstable_tree_search_insert) is saved. interesting, this is some useful information that you could have written in the cover letter and/or commit messages, to explain why you are proposing these changes :) > > > > >why is it so important to know how many zero pages have been merged? > >and why do you want to unmerge them? > > Zero pages may be the most common merged pages in actual environment(not only VM but also interesting information, which you could also have written in the cover letter and/or commit messages > also including other application like containers). Sometimes customers (app developers) > are very interested in how many non-zero-pages are actually merged in their apps. > > > > >the important thing is that the sysadmin knows how much memory would be > >needed to do the unmerge, and that information is already there. > > > > I think it's about chicken-and-egg problem. > > > Anyway, thanks for your reply. >