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 C1F55C7EE26 for ; Mon, 22 May 2023 10:43:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38B39900003; Mon, 22 May 2023 06:43:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33D70900002; Mon, 22 May 2023 06:43:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22A57900003; Mon, 22 May 2023 06:43:17 -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 120C4900002 for ; Mon, 22 May 2023 06:43:17 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CB500140CDB for ; Mon, 22 May 2023 10:43:16 +0000 (UTC) X-FDA: 80817553992.09.F489431 Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) by imf02.hostedemail.com (Postfix) with ESMTP id 4914980017 for ; Mon, 22 May 2023 10:43:13 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf02.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=1684752195; 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=RY4OBuWbPSJknOEnZ6Y/K51qo27uJkHgPFHMYzREBSg=; b=TNCG+XUGb/c6vEU2hzyNvlcM1258cqmT09GCYelHntmaNF4Bccmg+fKm12q1/t4YjkB7jI 6P51MzSHySfUKstAEafAGZuKQIKdfCFeJ+i7jYN/WFX4DRmUtNNuFqd7BrowPyYRLorcoy m2YMYJfJk+8zkWX4T1fyaLP80qen6uI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf02.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=1684752195; a=rsa-sha256; cv=none; b=LgJX37q7ig6/I9BMsIl+HjfYynP0EuVBHp7xO6QNCY0pD5KwKheU5Hiqg7sRhNqBbMgQqo crt6NfXEHyiepv91rEIWoKpoXwBAKL8dMqRdq0fCeFzkOMCRwoFd/+M5R+/vrr2Ziuu+rL m12YcO31t8hLaBeqbvhM9PwZ7ElDeIw= 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 4QPvDZ1f2gz5B150; Mon, 22 May 2023 18:43:10 +0800 (CST) Received: from szxlzmapp05.zte.com.cn ([10.5.230.85]) by mse-fl2.zte.com.cn with SMTP id 34MAgtsP031085; Mon, 22 May 2023 18:42:55 +0800 (+08) (envelope-from yang.yang29@zte.com.cn) Received: from mapi (szxlzmapp03[null]) by mapi (Zmail) with MAPI id mid14; Mon, 22 May 2023 18:42:58 +0800 (CST) Date: Mon, 22 May 2023 18:42:58 +0800 (CST) X-Zmail-TransId: 2b05646b4732682-6bb12 X-Mailer: Zmail v1.0 Message-ID: <202305221842587200002@zte.com.cn> Mime-Version: 1.0 From: To: , Cc: , , , , , , , Subject: =?UTF-8?B?W1BBVENIIHY4IDAvNl0ga3NtOiBzdXBwb3J0IHRyYWNraW5nIEtTTS1wbGFjZWQgemVyby1wYWdlcw==?= Content-Type: text/plain; charset="UTF-8" X-MAIL:mse-fl2.zte.com.cn 34MAgtsP031085 X-Fangmail-Gw-Spam-Type: 0 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 646B473E.000/4QPvDZ1f2gz5B150 X-Rspam-User: X-Stat-Signature: nn7cxhr3wdspucwzncawha8dg8915k16 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 4914980017 X-HE-Tag: 1684752193-526760 X-HE-Meta: U2FsdGVkX1/8xUOavhZ7pdXiiswyXEb9M14JhEaRY+Nv7I+pOZO6zEEIasbR8/aRm9vRIli7e0NQsUz/dZ9+5WsPTmRPeXAw7vLTDwgSCixmbc8vGtwVAsAcyKROt6DKgHNwaz/z72bfDUO5rZyrRlj5XSqBVx1QNRiT/+bU5TuZQspDDOZbl2iYff32ICXkMHJrWHg35ApZbV+aHXo/8BgzfGFd21LvA/tfh0kcyBfAN7okocVFh4MsP9+x14MBV8Mb6DdmsHyUFXmHqbPtU9kXBt1i9pXmPVw84PJbuE+VN6bcXNsmpsL9hBzyt1YEGSGUbt+XFdl0BL0+zUjy4xQu46CumgcPxu94iG9yI6A4CAI2oohLtrqOZ2UPFVXjn1k298zzMoON2Q5tZ6uVgUUz+ni2HatUpt/6wyqvLOsZ8CQCipOgTez4aL9y18T736jqT5d7Z0TmST2tO5YHAqrlN2hvTsygldbeSuMC7mfJ77Rvucj+H+pjYAQeeP6HwQLHRuSp4HrQN6n1nMA7dYFxqLcYqEXSX1t4YoZyHFEop6DvR+2tfMK2esGLApP3vExZIRW53Pz+fIpt9RxykaD5ztJfAhDU0AtMiIxzhY4bVooonYQZOKxkMD/rd9ifnzRCF4JjclPJRNXS2vdoKgtbBJyBVSj706/yn3BAd7eywvnE5Sdl36hSb1TM5WfuncjbvlS6aK71p4jt2BW44E0HRXIQQ8jxrw2oGKtz5ynhxT0idzC6wx2RPEMzSM4GQvLmmcRBTZQBOBmG4+EGPCwlB/IdO8vDDPgfJSXFdWkTk4XAMB5AvxldV9khky2JstCSpTq/I4dtYR1S3mKjw04ks14viU1/cPSuRba9BKbq775i40GZ2cBVMZ7M0i11NKVzzMuEHh3KNMRHOyJl8XTGQMc9hpSQnYdJV8gOvobw7rdky/IAc5Ojv1Im7SmuPJ5vCXyYRPhplqrLCLo 4X5udtG9 usnFIr9XQ3HW06XvXdDNQfwfaXdleHzxUo179Lc1IAx8i6NL7Tx+q781H2VksrljVS3E5DbXHe32zb+9MtxlpoAhXE6vptDTq2O+fnBTqyH218swoJH11Mr3aDgYzqeOWZ7LImQrqR8LAh5oVqZ62VuHEjymQ9edgZTI97vvAnFghWtSgNk94oZ5E7bLaguolt/7ma3/V5siHBUMJZkUeh7Nl5kdz+v6MXksYOznfDUB8ofQCEyaIQVTZKV43oRehI1iCGXJrjv8coZbFxcwpAfstFwgy9xRtQ1Nmq4LCIAHZ/HmIpDeTW2yuyB9Ag+0kJldOZrTaBykXHKGne1X5O34NKeTmuCpbn1h10Dq8rMN2/8DX0YL4niYBOoJfcNs2HIr/FcVI6RAU3Io= 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 ---------- 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 (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 | 1 + include/linux/ksm.h | 25 ++++++++ include/linux/mm_types.h | 9 ++- mm/khugepaged.c | 3 + mm/ksm.c | 19 +++++- mm/memory.c | 7 ++- tools/testing/selftests/mm/ksm_functional_tests.c | 75 +++++++++++++++++++++++ 8 files changed, 152 insertions(+), 13 deletions(-) -- 2.15.2