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 09F3CC433F5 for ; Thu, 29 Sep 2022 11:51:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 381348D0001; Thu, 29 Sep 2022 07:51:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3302E6B0073; Thu, 29 Sep 2022 07:51:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D0708D0001; Thu, 29 Sep 2022 07:51:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0DC256B0072 for ; Thu, 29 Sep 2022 07:51:10 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BC447ABA9A for ; Thu, 29 Sep 2022 11:51:09 +0000 (UTC) X-FDA: 79964957058.18.AC7FFB5 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf12.hostedemail.com (Postfix) with ESMTP id 62C1340009 for ; Thu, 29 Sep 2022 11:51:08 +0000 (UTC) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28TAHABR010789; Thu, 29 Sep 2022 11:51:07 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=A4zCAojyhaX0zj1bMbcNKc6QlqyIXmr15eUuzkx5w0s=; b=kxZ6yFlBmtnv4l2VX5aWSJPkvB/hVcaxeIRtS0dtOrtbjMIEoAm3scJ6Q36KJO7aW0R7 RwFzbLLqxFB6zX7vPf55Ougyuv8ZbszpPlYIWbMqBMDywFFhVwmwf6OcV9pNMnD4d4xu 9fIqcwp+tr5CzwkZLWkdK1egl1qrE3tkXjy9UqpaLBfQZs8Elg9F743mX6UUP/jerj+i kmf2oViycp5A2ma8EKqrk53RB53VjPwAg5O2/PA/8O5RuLv+BhSHrJMd3Y8bnewaM3Gx EhvD59ZXekLpQDXfhBhwnbB1W/F1rnzjfYjr1OlM3JW0Qke7WtROpdc6XMPu/Od91Rm7 Yw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jw9fs2dmg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Sep 2022 11:51:07 +0000 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 28TBIEkT028956; Thu, 29 Sep 2022 11:51:07 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jw9fs2dkh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Sep 2022 11:51:06 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 28TBZmZd018885; Thu, 29 Sep 2022 11:51:05 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma06ams.nl.ibm.com with ESMTP id 3jss5j6mur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Sep 2022 11:51:05 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 28TBp2dY27001252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Sep 2022 11:51:02 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9B16B11C058; Thu, 29 Sep 2022 11:51:02 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 58ACC11C052; Thu, 29 Sep 2022 11:51:02 +0000 (GMT) Received: from p-imbrenda (unknown [9.152.224.242]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 29 Sep 2022 11:51:02 +0000 (GMT) Date: Thu, 29 Sep 2022 13:51:00 +0200 From: Claudio Imbrenda To: David Hildenbrand Cc: xu.xin.sc@gmail.com, akpm@linux-foundation.org, imbrenda@linux.vnet.ibm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xu xin Subject: Re: [PATCH 0/3] ksm: fix incorrect count of merged pages when enabling use_zero_pages Message-ID: <20220929135100.5efe6229@p-imbrenda> In-Reply-To: <889909f6-f2db-f34a-0305-eb8500dd5453@redhat.com> References: <20220929025206.280970-1-xu.xin16@zte.com.cn> <20220929124242.60ef57ee@p-imbrenda> <889909f6-f2db-f34a-0305-eb8500dd5453@redhat.com> 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-GUID: 3t-joj1E5mP_f9Zr0iiO100prQXRdrQW X-Proofpoint-ORIG-GUID: SpT5_yv5EgnrGPhGOJUdrKpT7JLPOAdV 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-09-29_06,2022-09-29_03,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 impostorscore=0 mlxlogscore=642 spamscore=0 clxscore=1015 lowpriorityscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 mlxscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209290071 ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=kxZ6yFlB; spf=pass (imf12.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664452268; a=rsa-sha256; cv=none; b=kHi6Gh4qS8R4LYxhy/w2mx1jmddGGeKaEvOOIiM6if3gY1L2RqASHC/WVDvwdYZEUL5xn6 k24q3eg4179iHUcXlaI83UvWOaERCYQncA2zn3KA0xrMzChYKf1smCjxIj6D5trLk5qxp1 2n191VStqJj6+laqRkhRSJS9jV01RV8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664452268; 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=A4zCAojyhaX0zj1bMbcNKc6QlqyIXmr15eUuzkx5w0s=; b=XhV3LPSJZNuEBZWOz0osmRBEFCxGGfFxzAAthJnbgTY3yzzZslfLkD3tAjnR76W0KYbq6z l6YwKEjXmv/GYoZg+qRpFKapCbSwkxr132HS2Xq80TcZflF8Omiq+plNlf7IlWeWlhJdTH BEj59lImq6M/Pm+Kiwa3RZ4Q9VvBtvE= X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 62C1340009 X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=kxZ6yFlB; spf=pass (imf12.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: gqz6qjkeqckyuudr6iqnqzp3jj3u4bj4 X-HE-Tag: 1664452268-485833 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 Thu, 29 Sep 2022 13:34:24 +0200 David Hildenbrand wrote: > On 29.09.22 12:42, Claudio Imbrenda wrote: > > On Thu, 29 Sep 2022 02:52:06 +0000 > > xu.xin.sc@gmail.com wrote: > > > >> From: xu xin > >> > >> Before enabling use_zero_pages by setting /sys/kernel/mm/ksm/ > >> use_zero_pages to 1, pages_sharing of KSM is basically accurate. But > >> after enabling use_zero_pages, all empty pages that are merged with > >> kernel zero page are not counted in pages_sharing or pages_shared. > > > > that's because those pages are not shared between different processes. > > They are probably the most shared pages between processes in the kernel. shared from the kernel, though, not from other processes (that's what I meant) > They are simply not KSM pages, that's what makes accounting tricky here. exactly. and those pages get shared all the time even without KSM, so why care about those now? does it make a difference why a page is a zero page? > > > > >> That is because the rmap_items of these ksm zero pages are not > >> appended to The Stable Tree of KSM. > >> > >> We need to add the count of empty pages to let users know how many empty > >> pages are merged with kernel zero page(s). > > > > why? > > > > do you need to know how many untouched zero pages a process has? > > > > does it make a difference if the zero page is really untouched or if it > > was touched in the past but it is now zero? > > I'd also like to understand the rationale. Is it about estimating memory > demands when each and every shared page could get unshared? >