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 D23F7C77B6C for ; Thu, 13 Apr 2023 05:46:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2554900002; Thu, 13 Apr 2023 01:46:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EADDE6B0074; Thu, 13 Apr 2023 01:46:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D4DB5900002; Thu, 13 Apr 2023 01:46:58 -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 C1AFE6B0072 for ; Thu, 13 Apr 2023 01:46:58 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 96AA1120134 for ; Thu, 13 Apr 2023 05:46:58 +0000 (UTC) X-FDA: 80675284116.12.9A0D81B Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) by imf07.hostedemail.com (Postfix) with ESMTP id 7094E40004 for ; Thu, 13 Apr 2023 05:46:55 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf07.hostedemail.com: domain of yang.yang29@zte.com.cn designates 63.216.63.35 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=1681364815; 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=IlGuldjKLcEGrpuvwIk0b1HBgjiAyBs1a3eiLygBCz4=; b=6LpXqTeVb5FEi17xtU0ywblXkEiIpRYtGjbf7N3EV1YlBg0hFgCBUZJ/28DU7pc8GyGRzd Joznok78e8GhHqEm5PkIBMeSYC//njsdoTb3TtWHW7cQqsQw4zttuv9xX5g2EXHWM1CDLP TmrvvwesgW+Jg6xvQeU7EOuphWsjXvc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf07.hostedemail.com: domain of yang.yang29@zte.com.cn designates 63.216.63.35 as permitted sender) smtp.mailfrom=yang.yang29@zte.com.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681364815; a=rsa-sha256; cv=none; b=yw5YzbvOwkSVEcJr1p/46l2D+3sM195J6OBBLDVWW/Wpziv/AKHVntVsQ15GBEEfMGQV4E eYMbunHEUEoEEhZR2jbCsESqdQ1pBJQ8Vu2mYFlSYXBW4EFCvs1hcheR7pPPffUrh+qXiX ANQTBFj9uC1umlHsOne3UUuSepSII7k= Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (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 4PxpVg6Yncz4xVnK; Thu, 13 Apr 2023 13:46:51 +0800 (CST) Received: from szxlzmapp06.zte.com.cn ([10.5.230.252]) by mse-fl2.zte.com.cn with SMTP id 33D5klSF069087; Thu, 13 Apr 2023 13:46:47 +0800 (+08) (envelope-from yang.yang29@zte.com.cn) Received: from mapi (szxlzmapp01[null]) by mapi (Zmail) with MAPI id mid14; Thu, 13 Apr 2023 13:46:48 +0800 (CST) Date: Thu, 13 Apr 2023 13:46:48 +0800 (CST) X-Zmail-TransId: 2b0364379748ffffffffc3a-dc384 X-Mailer: Zmail v1.0 Message-ID: <202304131346489021903@zte.com.cn> Mime-Version: 1.0 From: To: , Cc: , , , , , , Subject: =?UTF-8?B?W1BBVENIIHY3IDAvNl0ga3NtOiBzdXBwb3J0IHRyYWNraW5nIEtTTS1wbGFjZWQgemVyby1wYWdlcw==?= Content-Type: text/plain; charset="UTF-8" X-MAIL:mse-fl2.zte.com.cn 33D5klSF069087 X-Fangmail-Gw-Spam-Type: 0 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 6437974B.000/4PxpVg6Yncz4xVnK X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7094E40004 X-Stat-Signature: uj1bdss9hq3kbbkeht7zepre9s18qtoy X-HE-Tag: 1681364815-193688 X-HE-Meta: U2FsdGVkX194keh4tpUJSpDLzij/NB+LMfSlUJmzFK375o6ZxM1gM8JxJOgX8OtmgMDziQ0//4wazJBuC7EWNJzx6waDd8yIpSzTj1FOudx++rPVWBVPYwVUnvR8kJhXp66kAoqO18XwBsOS24khE0rBrRQ6XHKiXBBGIiZyPG4Z8zAZf45pEBxcT7U3Srd2vOnGQEIwyrwnFpe+2DCQQO3qR42jEULcSVDMpP/AD3oz3lkbhf8gNDwZxlw2Tee4PkYrPaVXn62JQTko/9VcQHv/xwUcsvJ9wHwARAL5db9N50xTwO1+cFF1zuVjFDP5OGEOoenShJn9ytJcY4vp1ZT57Yjavz223iPZxao1gTnha9P2p5CAXx3XusvkdE2xx/w1nvRBeglYdFbYlR0aOFhndb6Z0bxi0PjSxQxN6hCd3clQwDAxKrlAwt5MEisnLt3HamBC/Ywn7as+yxOy1wz6bRsV0x4ndC6HuioIKziDn/YVkxHiBInFaqvYzw9taslRxBqNgW7WXDNG/MTx9pOx7TBWUZs5fVpc+fcuj21dFwJUJVKivkwK181Al+r3C/SyoFwmsuW9KgBsgOU+fSo4HmcAWbLs4xNsxvOQkOWu+r6wGRKMtFdolNbEsD9A7/+/dYHQWENbyDNXAYRoh5Rvi75xfvSI6RNivEPi4NVDiqugABKD4y3exjDYnurznDgr5D3zSOdzz+IACekDuRA4am2VkitJyoCDrnDALGlYUWHFJzZxaj/bS2UMZr4q9cv2Nch8KsmjZ6Gs1jx+Kn+70/j7do5bzgo/jjXnEREvYLcMkVxoQwc15KHHd82CwHEr7X5Ak0mw6d7iS1C7ImPSL7a/YJVcQMRA8gggt7FJAwi0oUT4ikf/k668bWyNpekHXW86wBM1KC/M7l5LjaXYk7tCe/vYLc2LgvHDvIQp8jiPej0Ad31qkFcIW9Cujwtl0dtY7dKwvOBtfNj wsErsziz JZSHwyGK4S21mOY8aiMlvNLdjjyYsQ1k+8Aco45kTn0Qg7+zPdapLcAvKOuXrEfV4SkyOf989RJ96NUtdNYMuV4l89zfEtgVm8Ew98R02d+AWKjxkRnYcp8RS1PV/Lbwf5eoTncY++mH0Xhx5Avo9gU08g0Cn9PZ6zW6S8lKo+fTV3+Ad9VuCQyyM7fUokXSXMhRgLvhoCMWlVy/aIyzQTPTbZc3kwK8I4ZQb2thmwXsOxExjIhfRawT/2rLPYK4zhaBUwMz2aGqT2mXXoH1FVCZK7TJCoRsNkGVU4lxnDEJHVOPDjfSk2+glOQn0aGM1fGZTKOlvGIX+cSR8NLvXz5mCMwAOdTa1vI6YDeN5FTjnHFb0NBnXvNGytJheqxajHYvz 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. the patch uses pte_mkdirty (related with architecture) to mark KSM-placed zero pages. Some architecture(like sparc64) treat R/O dirty PTEs as writable, which will break KSM pages state (wrprotect) and affect the KSM functionality. For safety, we restrict this feature only to the tested and known-working architechtures (ARM, ARM64, and X86) fow now. Change log ---------- 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 (6): ksm: support unsharing KSM-placed zero pages ksm: count all zero pages placed by KSM ksm: add ksm zero pages for each process ksm: add documentation for ksm zero pages ksm: update the calculation of KSM profit selftest: add a testcase of ksm zero pages Documentation/admin-guide/mm/ksm.rst | 26 +++++--- fs/proc/base.c | 3 + include/linux/ksm.h | 27 ++++++++ include/linux/mm_types.h | 11 +++- mm/Kconfig | 23 ++++++- mm/ksm.c | 28 ++++++++- mm/memory.c | 7 ++- tools/testing/selftests/mm/ksm_functional_tests.c | 75 +++++++++++++++++++++++ 8 files changed, 187 insertions(+), 13 deletions(-) -- 2.15.2