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 F0C82C433F5 for ; Thu, 29 Sep 2022 10:36:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64B518D0002; Thu, 29 Sep 2022 06:36:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FB1C8D0001; Thu, 29 Sep 2022 06:36:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 474338D0002; Thu, 29 Sep 2022 06:36:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 33C968D0001 for ; Thu, 29 Sep 2022 06:36:41 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F30EB16111C for ; Thu, 29 Sep 2022 10:36:40 +0000 (UTC) X-FDA: 79964769360.08.868F46B Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf24.hostedemail.com (Postfix) with ESMTP id 6CC08180013 for ; Thu, 29 Sep 2022 10:36:39 +0000 (UTC) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28TAM2td005732; Thu, 29 Sep 2022 10:36:38 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=MlPAGWC974VFWedeJYZKhv+TzRCwfMG8iyZ078IdKCQ=; b=N/a9md72XcfdUB9ZiidvBKMXnwuAz5PwQI/F1EcjuNhh1dDyPEeD46Fe9uPonzmaNW5n vcZkKl4ItuIxmX5/2NOsxuGPfGXebkJUPplOlMupXv0d1fihfI9+igyBdfh6D4D/5Sl4 WGJs+izvhWvLm4T5HhcYvTQ+Rv/4Bfdqh7AwqdIFq1lrj5MZ0r75tsUlHFHjOTMBe6vH UGedlrAN41FDrFnVWuwVityAnXWTTmoSR20oTPPs2LznB2lC/73drWtGLG7g0F5J7OZm sqiL6zIxy64sMKj7noJAqIxXXVfiYpGz6w37MMf4MHyOP2xAgOUgYeSPybovMh7XD2O0 JA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jw9j10bsw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Sep 2022 10:36:38 +0000 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 28TAMaqr007811; Thu, 29 Sep 2022 10:36:37 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 3jw9j10brv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Sep 2022 10:36:37 +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 28TAaCq3005466; Thu, 29 Sep 2022 10:36:35 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma06ams.nl.ibm.com with ESMTP id 3jss5j6jas-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Sep 2022 10:36:34 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 28TAaWPw39321858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Sep 2022 10:36:32 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8BB94A4069; Thu, 29 Sep 2022 10:36:32 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4084AA4064; Thu, 29 Sep 2022 10:36:32 +0000 (GMT) Received: from p-imbrenda (unknown [9.152.224.242]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 29 Sep 2022 10:36:32 +0000 (GMT) Date: Thu, 29 Sep 2022 12:36:30 +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: <20220929123630.0951b199@p-imbrenda> In-Reply-To: <4a3daba6-18f9-d252-697c-197f65578c44@redhat.com> References: <20220929025206.280970-1-xu.xin16@zte.com.cn> <4a3daba6-18f9-d252-697c-197f65578c44@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: rw9PYcmB7cdoc5FCSt3K3DVh4ZmgNg8q X-Proofpoint-ORIG-GUID: W39x4KoEUMvY6iEbDi-S6ckETqe_BaZU 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 priorityscore=1501 mlxlogscore=860 malwarescore=0 suspectscore=0 adultscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 spamscore=0 phishscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209290064 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664447799; 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=MlPAGWC974VFWedeJYZKhv+TzRCwfMG8iyZ078IdKCQ=; b=LEJR15OxWJYlYXGVwbwJeHGmciKmTv4TChvwkNhysOa8Lep3OMl5UFPSEh7abbpZd1pub1 fPOv/FZ0nymbKrUBL/NmkXRLKf9Jng2U2gNtfsIIpt1LUNOpqblZQHPcT7bhbexhN00cZN nKYIWJ5+7oOkFR+HLY94xMLQ0mWIUKQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b="N/a9md72"; spf=pass (imf24.hostedemail.com: domain of imbrenda@linux.ibm.com designates 148.163.156.1 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=1664447799; a=rsa-sha256; cv=none; b=lSOn279cD0aYnChQNcxgQCnRUxbW3CZlITLHUQfotN+sfEU2X8/ZoH9iHVgqNc1GOKomxw /9x+ZjhUOatZiNx/HdProwx0wNDC3nk1tW75AFXAyplZPRHRF+YrZb7JsEZMJb3BcoxjPN tQh2BrMr4zafQtHU+UbhFRGNaJYVdYU= Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b="N/a9md72"; spf=pass (imf24.hostedemail.com: domain of imbrenda@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=imbrenda@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com X-Rspam-User: X-Stat-Signature: o1iq3p6eff1zkxxbxufq3jr87uik6adz X-Rspamd-Queue-Id: 6CC08180013 X-Rspamd-Server: rspam08 X-HE-Tag: 1664447799-942671 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 11:21:44 +0200 David Hildenbrand wrote: > On 29.09.22 04:52, 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 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). > > > > Please see the subsequent patches for details. > > Just raising the topic here because it's related to the KSM usage of the > shared zero-page: > > MADV_UNMERGEABLE and other ways to trigger unsharing will *not* unshare > the shared zeropage as placed by KSM (which is against the > MADV_UNMERGEABLE documentation at least). It will only unshare actual > KSM pages. We might not want want to blindly unshare all shared > zeropages in applicable VMAs ... using a dedicated shared zero (KSM) > page -- instead of the generic zero page -- might be one way to handle > this cleaner. I don't understand why do you need this. first of all, one zero page would not be enough (depending on the architecture, e.g. on s390x you need many). the whole point of zero page merging is that one zero page is not enough. second, once a page is merged with a zero page, it's not really handled by KSM anymore. if you have a big allocation, of which you only touch a few pages, would the rest be considered "merged"? no, it's just zero pages, right? this is the same, except that we take present pages with zeroes in it and we discard them and map them to zero pages. it's kinda like if we had never touched them. > > Would that also fix some of the issues you describe above? >