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 9AE5AC433FE for ; Thu, 29 Sep 2022 11:13:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 372F48D0005; Thu, 29 Sep 2022 07:13:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 322718D0001; Thu, 29 Sep 2022 07:13:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EAB18D0005; Thu, 29 Sep 2022 07:13:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0F2128D0001 for ; Thu, 29 Sep 2022 07:13:21 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E3491A0390 for ; Thu, 29 Sep 2022 11:13:20 +0000 (UTC) X-FDA: 79964861760.05.8737A1D Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf03.hostedemail.com (Postfix) with ESMTP id 8BDF420007 for ; Thu, 29 Sep 2022 11:13:20 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id b23so1136179pfp.9 for ; Thu, 29 Sep 2022 04:13:20 -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=1M4otbErkQwsCcWWge6AN/K/OZ3vG8NZphh6FyslJSs=; b=qY21oUgR2rChPGf1JnQpAXyhW0MEMzMYkkt5oenaaWSrbYd/slLFU3PjRHkipX93JE DB6xo6HFOj+Vi38gAISa2j3Jh89Jc7NaOp+AfI71/rc8GR/g/KPCmpXK55ZGc+m8sfIO V4FKmS92eqQNC6LtGSOKe9TanTIKP0RzVDneqU3uA7do7por+CWboT4q1Pt29EuFw82g HaHMnHvBGtPVuRjmVYg4qvcY/TTfKsAv1YaXW8iKmqAPia85zIigxZ3QDow4DytmEhzL tc/7xqgMMePtinn6mGntin7yHqrhFTx1y6xEzPU7lI+zaXFRbkjaK53om6t84az05kdy GOxQ== 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=1M4otbErkQwsCcWWge6AN/K/OZ3vG8NZphh6FyslJSs=; b=IURYzU1CyvNpjQcdtrVx8myszyFquJ2G49DpfKIBngCc7Z4F0oi/c02NU9WIqtZP8n jnHFIXq/ooGEXC+8+VUPKtIII/Ase6X6SPz0CueJa/1wO6LkaG4dBvk1uFKiMt3lkG5F 6/twoj2t5P9aLmEanGerH8OCYAkDRjFxh+Ddw2DKGG1tFfC5SEDs0RrE3poi8knC9/XE wju6CgpuJM67wBdWOgB/5KRpVISBAdU/ohmNL/TZZSYBw63Fi8PWRQt/2NFU+peygoxz GSkjD6t/aop4SqqKgQkNz4s/Qi6L1L3fQ0GkOotm/YNk/aZTwvqdQd2WLjKPTkGXJH6j 1tmg== X-Gm-Message-State: ACrzQf2+zTWpBkOj3HbjBG+/6N0IKJNdtSQbM3rBAjqSW5LEKoLAmNk7 XKzI28Lq2OcVFkiv7kgIKIw= X-Google-Smtp-Source: AMsMyM4sMbWxVCuMTTWrY/4loMArjX5YJL8pT+fk2YDL6cZVdhUpt2RK9RpddofIfysdPsI8QG/Uxg== X-Received: by 2002:a63:4f19:0:b0:43b:ddc9:387c with SMTP id d25-20020a634f19000000b0043bddc9387cmr2374903pgb.333.1664449999527; Thu, 29 Sep 2022 04:13:19 -0700 (PDT) Received: from localhost.localdomain ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id a4-20020a1709027e4400b001768b6f9a97sm5566823pln.147.2022.09.29.04.13.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 04:13:19 -0700 (PDT) From: xu xin X-Google-Original-From: xu xin To: 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: Thu, 29 Sep 2022 11:13:15 +0000 Message-Id: <20220929111315.284133-1-xu.xin16@zte.com.cn> X-Mailer: git-send-email 2.25.1 In-Reply-To: <4a3daba6-18f9-d252-697c-197f65578c44@redhat.com> References: <4a3daba6-18f9-d252-697c-197f65578c44@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qY21oUgR; spf=pass (imf03.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.210.193 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=1664450000; a=rsa-sha256; cv=none; b=ZBN/7ybkrLcntDapO3KcrpuflrFWgBjEEt6Xa9aY2Ul0wovo/YxRqeouFNzP88jNp5sJaH P6qoXdi6BwKCfBuQYTr95Qovs23TtwCaTu2jOjGCVemZtP3zEjP732epq+X2BhOODWm+b/ HCpyqPKh+5BucmdbOQJF03IOMv3TFHA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664450000; 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=1M4otbErkQwsCcWWge6AN/K/OZ3vG8NZphh6FyslJSs=; b=W6dFOmV3R1KK3Fbc7isiRHnGYI2GZrpXNUe8xpq66xFyqfKWUtcpqOC3/lfelfYzvCYSXU q2dEpgs+tzfPqjByczo4L6A/etITJekIjgOsBIWeNMRV6UzHFZjrb9pvnOmPRjxFfDCA06 f3hyMQuGp+wRfc3DYf+DsaSzIS2Ct8I= X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8BDF420007 X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qY21oUgR; spf=pass (imf03.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.210.193 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: 9eoit9qfgraigcn819qn5k74hhybyua8 X-HE-Tag: 1664450000-943375 X-Bogosity: Ham, tests=bogofilter, spamicity=0.012756, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: >> 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. > Would that also fix some of the issues you describe above? Glad to see your reply. I think it depends. The way you said solves the issue you post, but maybe not help to solve the issue I post. The key lies in whether appending zeropage's rmap_items to stable tree. If appending their rmap_items to the stable tree, the issue I pointed can be fixed but that will degrade the performance of use_zero_pages. If not appending their rmap_items to the stable tree, we have to choose this patches set (but I found some bugs now, later I will send v2 to fix it).