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 32705C433F5 for ; Fri, 30 Sep 2022 02:00:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 868288E0002; Thu, 29 Sep 2022 22:00:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 817DA8E0001; Thu, 29 Sep 2022 22:00:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B73B8E0002; Thu, 29 Sep 2022 22:00:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5B3A78E0001 for ; Thu, 29 Sep 2022 22:00:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 29C3A141499 for ; Fri, 30 Sep 2022 02:00:38 +0000 (UTC) X-FDA: 79967097756.01.E077771 Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by imf16.hostedemail.com (Postfix) with ESMTP id B68FC180010 for ; Fri, 30 Sep 2022 02:00:37 +0000 (UTC) Received: by mail-pj1-f68.google.com with SMTP id x32-20020a17090a38a300b00209dced49cfso404499pjb.0 for ; Thu, 29 Sep 2022 19:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date; bh=4/ab8BYv2AidX31kl8PumGWwMuGpRG2q/otkt7COkmg=; b=mU1beNcqiH7b5gUXbFMc5nG0nEKui3AttDV+145oRJ2QDrvvA3dVNlvMR8e99OY70v JBOVb/vD7I7WztaJOAaGJ3z50adHGUbh7vYiKBDZ2CzD02ZG6d3cFzPmbIlHzPECwktI /WPHiidN0rl2BUgTAXoGdZN1T+tPKIKfFfGXWDzsolQMmRd1Av9DszE93Nx1nlYy0Wjq A/aaxJgnTGF4O1rU9D8c5Wp2h2lxal9n3loZ1MRPfc/VE+FAIoc9uftbVk/QrAc55mso F+T8xXZc9N3peKkr3lzzXNR8YAdzZ27Kh1ii6sSYsbSAjznCm0s6hyZfv0Tgkq86ajiy gK5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=4/ab8BYv2AidX31kl8PumGWwMuGpRG2q/otkt7COkmg=; b=0HBASBKOR+22TZ74A1Iq00hU+Eb1wNgjFP5UCUV0CiIFC7Ma29M52Oln+64Gubm5YA x0HxqKZI5nYaz9MRV70xkLpvNsEuLlRsqGaSxLFGhQV53z+K6w9IjA3ab4JL3BfBIuTf 2yN3eB31MfHvHpITVTdtb59QoMavTzjB0AQIAFfma9PhZbZRdUwvN93GybBW3vtdY0Il Z8mNOnp+DV0FG0wMz4e7j0L5d0PJo64cV20LbUrpo531EVksxFrk8hKiKkRMSOLQLbh6 ip9vQIL5s4Qkg7ybrePI7f3HYzfNuPuYC/qnPQOz4mSJc/c4X8lADPXoO4qxMw0VJf8D yQ2Q== X-Gm-Message-State: ACrzQf374dTdTf/wAIiJt2qI+remraBCpEdB6aAG9HEniWH40gsR2ACj KkFv2E8Eu97sNfPTMHaEzyU= X-Google-Smtp-Source: AMsMyM6jFlIQYSVdLHFBaTTZjNsObnlMFdv+1/xXFszvcj+XbBDLPzVaI5d4kskPdjEs44/raEPTng== X-Received: by 2002:a17:90b:3ec2:b0:202:b123:29cc with SMTP id rm2-20020a17090b3ec200b00202b12329ccmr19765597pjb.167.1664503236535; Thu, 29 Sep 2022 19:00:36 -0700 (PDT) Received: from localhost.localdomain ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id a7-20020aa794a7000000b0053818255880sm362090pfl.193.2022.09.29.19.00.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 19:00:36 -0700 (PDT) From: xu xin X-Google-Original-From: xu xin To: imbrenda@linux.ibm.com, david@redhat.com Cc: akpm@linux-foundation.org, imbrenda@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xu.xin.sc@gmail.com, xu.xin16@zte.com.cn Subject: Reply:[PATCH 0/3] ksm: fix incorrect count of merged pages when enabling use_zero_pages Date: Fri, 30 Sep 2022 02:00:32 +0000 Message-Id: <20220930020032.286941-1-xu.xin16@zte.com.cn> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220929135100.5efe6229@p-imbrenda> References: <20220929135100.5efe6229@p-imbrenda> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mU1beNcq; spf=pass (imf16.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.216.68 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664503237; a=rsa-sha256; cv=none; b=dnMnDzAt8NzUADk9n45vMaRMzN0GEx0d54D4QYgcLM+5r85LdGwH1W7L1D5h75XIA82LqF AclO8ggc8Geis4+3pPTCci0GQt5DvzZeMHr97FXsamnUcbUtwO7TM5qWIVrBxPaHtvCPXJ hYkjcXvvtmOYZ+SO7kRGVYygLLI3oes= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664503237; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4/ab8BYv2AidX31kl8PumGWwMuGpRG2q/otkt7COkmg=; b=dnsVNJ2nWiQBY68TzIzXgX1nAx06VIZLe1ApELWZk45BGavSjyJvSU2aNwv/2rprj+YyMw theo1/QdBqW80tBPrDJW3pnH43nG6QaOqOltl9sbPKmwR6Io659HiE40gAZiRuwnvRttHo 8FrbGVdb+h9kzuYmIIe1UrGf/04qXBY= X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B68FC180010 X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mU1beNcq; spf=pass (imf16.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.216.68 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: 9qi7anx157p6g8i41xg4fako4bq1txzm X-HE-Tag: 1664503237-197975 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 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? WI's necessary to show these sharing zeros pages. Because: 1) Turning on/off use_zero_pages shouldn't make it so not transparent with the sharing zero pages. When administrators enable KSM and turn on use_zero_pages, if much memory increases due to zero pages sharing but they don't know the reasons compared to turning off use_zero_pages, isn't it confusing? 2) If no need to let users know how many full-zero-filled pages are merged by KSM due to use_zero_pages, then also no need to show pages_sharing and pages_shared to users. Besides, the description of pages_sharing in Documentation is wrong and MISLEADING when enabling use_zero_pages. 3) As David supposes, it also help for estimating memory demands when each and every shared page could get unshared. > >> >> > >> >> 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? >> >