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 00571C7EE23 for ; Wed, 24 May 2023 05:51:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 789726B0074; Wed, 24 May 2023 01:51:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 738DA6B0075; Wed, 24 May 2023 01:51:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64EB0900002; Wed, 24 May 2023 01:51:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5424D6B0074 for ; Wed, 24 May 2023 01:51:49 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 087991208B0 for ; Wed, 24 May 2023 05:51:48 +0000 (UTC) X-FDA: 80824077138.03.A66B649 Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) by imf04.hostedemail.com (Postfix) with ESMTP id 5F97340002 for ; Wed, 24 May 2023 05:51:44 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf04.hostedemail.com: domain of yang.yang29@zte.com.cn designates 63.216.63.40 as permitted sender) smtp.mailfrom=yang.yang29@zte.com.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684907506; 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:in-reply-to: references; bh=9DpidUW141Xln9uQMmYA+IPozD1aChThrPC1MjiY0qs=; b=ZngTql8fdpmyUc7+6stTQTd2p7+K98EPWekXaK0uR6bgrAVDCesMHX6DqP0Acy0xP0k11o GRJy0k+vJRgMWj5gYwCyN7uZmEVzVC3TeUkumUVDsOMlFEblR/fMHLAd+vEbQXloGo1FYo WrD9iWO9i8KqavK5shUjeWpia51XKIg= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf04.hostedemail.com: domain of yang.yang29@zte.com.cn designates 63.216.63.40 as permitted sender) smtp.mailfrom=yang.yang29@zte.com.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684907506; a=rsa-sha256; cv=none; b=N+ydltdJLuEc3d0rdSntu287KMLhG04ChOzksivhFWZddbwyoGIM0LWpMKiPWlGunJc7Ah QrNkYT+EzJnX+AlvUyAQ6w+eb0cS5NubVasH7NEMZWY/Srx7evrzEcR9Ka7j0phoGEQgg+ 678ALcXaaoTtDZnMbLkjLenmQHKb1iA= Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4QR0gJ6zZ8z8RTWf; Wed, 24 May 2023 13:51:40 +0800 (CST) Received: from szxlzmapp01.zte.com.cn ([10.5.231.85]) by mse-fl1.zte.com.cn with SMTP id 34O5pY5c047952; Wed, 24 May 2023 13:51:34 +0800 (+08) (envelope-from yang.yang29@zte.com.cn) Received: from mapi (szxlzmapp03[null]) by mapi (Zmail) with MAPI id mid14; Wed, 24 May 2023 13:51:36 +0800 (CST) Date: Wed, 24 May 2023 13:51:36 +0800 (CST) X-Zmail-TransId: 2b05646da5e8ffffffffcd2-a2267 X-Mailer: Zmail v1.0 Message-ID: <202305241351365661923@zte.com.cn> Mime-Version: 1.0 From: To: , Cc: , , , , , , , Subject: =?UTF-8?B?W1BBVENIIHY5IDAvNV0ga3NtOiBzdXBwb3J0IHRyYWNraW5nIEtTTS1wbGFjZWQgemVyby1wYWdlcw==?= Content-Type: text/plain; charset="UTF-8" X-MAIL:mse-fl1.zte.com.cn 34O5pY5c047952 X-Fangmail-Gw-Spam-Type: 0 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 646DA5EC.001/4QR0gJ6zZ8z8RTWf X-Rspamd-Queue-Id: 5F97340002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ju3iig3ta89t3jr3k3aqtwhosousihy8 X-HE-Tag: 1684907504-409158 X-HE-Meta: U2FsdGVkX1+7mNx4XrQsMLHkl2TbRlhae0DCRS9SBSpUi+rihra2tZ+gfARBHwVwoyY3OcpqAKWMfE2sGfEBAEOtbg0z2BddQxd08g71D96a0K/upIqF2Ji/h9iV/sWA6Tf6jbTt+Gl4dDGKTBWLop9fuN00Wo2hUVCR+JKL/kSbby485L6qcFhs43eSKZTXP+iJwLv3RYEYQaI4yewKbR4seSHOz8FH8PK1K6ES+s2QhMAJQZEfKVMbH6iNxLNhTblHTNn+3KsKp8PfYBTBXZdqEfpT7WlG2MxLbyra/qdpQvYkGlkShhH38BQHcIPRC5gx8RwUABTQi7rSe4t5e+RpPtUYMk5TFDLqaFfUBfEO1no9iSxTvCi3AKBZPXqYtHlsHcJBcVevQXVQOSC2Zyhv1oCDlgiCtdmg8AzSzEDlXu4XlIe/4XZnpw2JCgP/5aDwwxAWk1LAWTqtUmmgCcid9HCQgEFCHePamNIftjh/vzTqZUOtXlnY4XL96cW+8SsJnHqyuKE+UQafYpBQNF4+wFh/bSv+H3L2XGlVa8IlDiZ3ynjioIx0LYX3a/Z3pdLoq+Bvjspchwcv17+hP0tCn9LS+1bQHYjzcLo4IgDRagLmM2jnRhBi3++SUk0ZMWJA5cKlR3hZJGbqzlmw9skqdpTVuDM+lwk3c8ojst0Lw0dAewG4If6mzDqyMbFfYcoZxMLaW04KtprHEAbNk7vBE9uuIs3RRMFsV+qyoK9JVlHU7unV3LOtGZSv9XKcerzerjmqAmalITp4VI5IOc8mteh4iHz9M4koNSFAtksXTKlehcNHoE70um24VK6QoeIxb1rBX8/5MWv6BflzDkMy4WUAglCg0x4rVf58hU+4Zb+WlkNLqy1+bkHqvFNRB+rEsUBt1tDl2UnXbcSwcEp8n1RdWe+H2K9cw0wfXzmTzqRMOUP2pLJ66qzazwLkW2iILsSZxvGGSyo9I3S T/N3ZgO1 IeW+b9gonm7V3ghqjU0ZB8wF3YBG6hvurK7m2tPESD6S0KaOCuxLX6+RJzT0K6L4nn0ufCmEa0+q7UojiqWXXkrdV9magvvrFO5rRqPjJSCq7JvWNu/0pbNv6aQEgrEB6bqAKwHmJoHpqFcZYh/PImnU7C4dLEyES8L6re92EARokkHDLhxLeOsNpyCnUOTLgobZcFFbrM1a3egQMpCzktFHgShnM6vLijx/Z3f4mnPiSk7UPqWrYFtSYJdG0cEYn/Qa1LGoWEi+s5iDgQoW7+uR1RUQp92CIrSmBygMh/3kdB0mQ5TG2Ded//W1au/Dn/ZZjXI4/EZJPM2z7V1Uggw+Nr2EbSsH+35iD3xm6cYcKQag7jDk6kLEH+NEfi4Kp4CUOsmN/EW7BckI= 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: From: xu xin The core idea of this patch set is to enable users to perceive the number of any pages merged by KSM, regardless of whether use_zero_page switch has been turned on, so that users can know how much free memory increase is really due to their madvise(MERGEABLE) actions. But the problem is, when enabling use_zero_pages, all empty pages will be merged with kernel zero pages instead of with each other as use_zero_pages is disabled, and then these zero-pages are no longer monitored by KSM. The motivations to do this is seen at: https://lore.kernel.org/lkml/202302100915227721315@zte.com.cn/ In one word, we hope to implement the support for KSM-placed zero pages tracking without affecting the feature of use_zero_pages, so that app developer can also benefit from knowing the actual KSM profit by getting KSM-placed zero pages to optimize applications eventually when /sys/kernel/mm/ksm/use_zero_pages is enabled. Change log ---------- v8->v9: ------ (1) The previous [PATCH v8 4/6] is squashed into the current [PATCH v9 2/5]. (2) Improve the codes as David's suggestions. v7->v8: ------- (1) Since [1] which fix the bug of pte_mkdirty on sparc64 that makes pte writable, then we can remove the architechture restrictions of our features. (2) Improve the scheme of update ksm_zero_pages: add the handling case when khugepaged replaces a shared zeropage by a THP. [1] https://lore.kernel.org/all/20230411141529.428991-2-david@redhat.com/ v6->v7: ------- This is an all-newed version which is different from v6 which relys on KSM's rmap_item. The patch series don't rely on rmap_item but pte_dirty, so the general handling of tracking KSM-placed zero-pages is simplified a lot. For safety, we restrict this feature only to the tested and known-working architechtures (ARM, ARM64, and X86) fow now. xu xin (5): ksm: support unsharing KSM-placed zero pages ksm: count all zero pages placed by KSM ksm: add ksm zero pages for each process ksm: consider KSM-placed zeropages when calculating KSM profit selftest: add a testcase of ksm zero pages Documentation/admin-guide/mm/ksm.rst | 25 ++++++-- fs/proc/base.c | 1 + include/linux/ksm.h | 22 +++++++ include/linux/mm_types.h | 9 ++- mm/khugepaged.c | 2 + mm/ksm.c | 28 ++++++-- mm/memory.c | 5 +- tools/testing/selftests/mm/ksm_functional_tests.c | 78 ++++++++++++++++++++++- 8 files changed, 154 insertions(+), 16 deletions(-) -- 2.15.2