From nobody Wed Apr 8 02:51:32 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BEA06C00140 for ; Wed, 24 Aug 2022 07:07:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234708AbiHXHHw (ORCPT ); Wed, 24 Aug 2022 03:07:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234428AbiHXHHu (ORCPT ); Wed, 24 Aug 2022 03:07:50 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 89A4385FF9; Wed, 24 Aug 2022 00:07:49 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id pm13so7266819pjb.5; Wed, 24 Aug 2022 00:07:49 -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; bh=PXafh5f+pigI8lTygHH0lurdqVrGUMub4Gos5atZnOQ=; b=HsdOV6X0ITgH2yGuQ3b98iiy8QNVcOLPz8ObGnZUz5a7ATRlrUzRTDHNLfsUrNG+qY OP3oKeKkjbewVjarYo1XUABAuOR+w9ye8pTUiHS8fCbP1GZv4J+DJw3HDWOij9WEXSID 1WeLvvlf+oerfF8O8Iu1t/8mHftJVnGAceyjfudLCbcNHuidZJJCa0P9na4ZbABt6DGM WcIB0nGznps1CxEY3SbcdpH6vggWfQCKu+Rh41HIXsDoKAMYyiwHCW4xElaRqIqEXTMB Nuhfuo7VF6KOQqv4cCInEQCUZJP9g2Hjk4QYFxIRRasmj2jD/lQN5nYmfzynHEypu+W+ FWBA== 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; bh=PXafh5f+pigI8lTygHH0lurdqVrGUMub4Gos5atZnOQ=; b=d2gHzjQkIuFqQnwj4KNmDUNUr4WrmufQdsLKnnZmDYQ55Ab0ldeL1KbJBT4olzbS2v DcxDMEk9stylU8JOFU8FzZva6WULWnHrfEPhJRRKra0lBv8+x+vOgMdYuchpAXFV3+9F 8crYTungmMm3dvBGy6r2kF9ZRevdY5hZrODMKJSPf/439WtvTO2stxLHoxVu0vysUIqU vMYg5US2qB9ukMa2LSaOCbM09ZL5+g8fPlTxOvM576/LBkcAUuGfuC8ulwbAJyx9EgrJ SUEyv3uLniVcaHpnCYYIao0HBcgKDtNCEX7hbqFOG4cPVj2BAKOj/siHypvdFO9wzAqz 2n/w== X-Gm-Message-State: ACgBeo38/Bb0LHM6E4pZjyLebECP11+XyK8VXcWWTHBmKYKBZrXyGifS fNvmgDdWafYCP+c7FpArhXU= X-Google-Smtp-Source: AA6agR4pw6w0HuTOmjtqzCYa/gYOpKO0DzmiYndqTYq3H/EuqbX7SSXSaG7zatYXeRMMNAu1UX7Kpg== X-Received: by 2002:a17:90b:3149:b0:1fb:71ad:256b with SMTP id ip9-20020a17090b314900b001fb71ad256bmr4679326pjb.18.1661324869038; Wed, 24 Aug 2022 00:07:49 -0700 (PDT) Received: from localhost.localdomain ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id z12-20020aa7948c000000b00535c4b7f1eesm12118187pfk.87.2022.08.24.00.07.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 00:07:48 -0700 (PDT) From: xu xin X-Google-Original-From: xu xin To: akpm@linux-foundation.org, corbet@lwn.net Cc: bagasdotme@gmail.com, adobriyan@gmail.com, willy@infradead.org, hughd@google.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, xu xin , Xiaokai Ran , Yang Yang , CGEL ZTE Subject: [PATCH v3 1/2] ksm: count allocated ksm rmap_items for each process Date: Wed, 24 Aug 2022 07:07:38 +0000 Message-Id: <20220824070738.220038-1-xu.xin16@zte.com.cn> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220824070559.219977-1-xu.xin16@zte.com.cn> References: <20220824070559.219977-1-xu.xin16@zte.com.cn> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" KSM can save memory by merging identical pages, but also can consume additional memory, because it needs to generate rmap_items to save each scanned page's brief rmap information. Some of these pages may be merged, but some may not be abled to be merged after being checked several times, which are unprofitable memory consumed. The information about whether KSM save memory or consume memory in system-wide range can be determined by the comprehensive calculation of pages_sharing, pages_shared, pages_unshared and pages_volatile. A simple approximate calculation: profit =3D~ pages_sharing * sizeof(page) - (all_rmap_items) * sizeof(rmap_item); where all_rmap_items equals to the sum of pages_sharing, pages_shared, pages_unshared and pages_volatile. But we cannot calculate this kind of ksm profit inner single-process wide because the information of ksm rmap_item's number of a process is lacked. For user applications, if this kind of information could be obtained, it helps upper users know how beneficial the ksm-policy (like madvise) they are using brings, and then optimize their app code. For example, one application madvise 1000 pages as MERGEABLE, while only a few pages are really merged, then it's not cost-efficient. So we add a new interface /proc//ksm_rmp_items for each process to indicate the total allocated ksm rmap_items of this process. Similarly, we can calculate the ksm profit approximately for a single-process by: profit =3D~ ksm_merging_pages * sizeof(page) - ksm_rmp_items * sizeof(rmap_item); where ksm_merging_pages and ksm_rmp_items are both under /proc//. Signed-off-by: xu xin Reviewed-by: Xiaokai Ran Reviewed-by: Yang Yang Signed-off-by: CGEL ZTE --- fs/proc/base.c | 15 +++++++++++++++ include/linux/mm_types.h | 5 +++++ mm/ksm.c | 2 ++ 3 files changed, 22 insertions(+) diff --git a/fs/proc/base.c b/fs/proc/base.c index 4ead8cf654e4..9977e17885c2 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -3199,6 +3199,19 @@ static int proc_pid_ksm_merging_pages(struct seq_fil= e *m, struct pid_namespace * =20 return 0; } +static int proc_pid_ksm_rmp_items(struct seq_file *m, struct pid_namespace= *ns, + struct pid *pid, struct task_struct *task) +{ + struct mm_struct *mm; + + mm =3D get_task_mm(task); + if (mm) { + seq_printf(m, "%lu\n", mm->ksm_rmp_items); + mmput(mm); + } + + return 0; +} #endif /* CONFIG_KSM */ =20 #ifdef CONFIG_STACKLEAK_METRICS @@ -3334,6 +3347,7 @@ static const struct pid_entry tgid_base_stuff[] =3D { #endif #ifdef CONFIG_KSM ONE("ksm_merging_pages", S_IRUSR, proc_pid_ksm_merging_pages), + ONE("ksm_rmp_items", S_IRUSR, proc_pid_ksm_rmp_items), #endif }; =20 @@ -3671,6 +3685,7 @@ static const struct pid_entry tid_base_stuff[] =3D { #endif #ifdef CONFIG_KSM ONE("ksm_merging_pages", S_IRUSR, proc_pid_ksm_merging_pages), + ONE("ksm_rmp_items", S_IRUSR, proc_pid_ksm_rmp_items), #endif }; =20 diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index d6ec33438dc1..a2a8da1ccb31 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -656,6 +656,11 @@ struct mm_struct { * merging. */ unsigned long ksm_merging_pages; + /* + * Represent how many pages are checked for ksm merging + * including merged and not merged. + */ + unsigned long ksm_rmp_items; #endif #ifdef CONFIG_LRU_GEN struct { diff --git a/mm/ksm.c b/mm/ksm.c index a98bc3beb874..66d686039010 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -387,6 +387,7 @@ static inline struct rmap_item *alloc_rmap_item(void) static inline void free_rmap_item(struct rmap_item *rmap_item) { ksm_rmap_items--; + rmap_item->mm->ksm_rmp_items--; rmap_item->mm =3D NULL; /* debug safety */ kmem_cache_free(rmap_item_cache, rmap_item); } @@ -2231,6 +2232,7 @@ static struct rmap_item *get_next_rmap_item(struct mm= _slot *mm_slot, if (rmap_item) { /* It has already been zeroed */ rmap_item->mm =3D mm_slot->mm; + rmap_item->mm->ksm_rmp_items++; rmap_item->address =3D addr; rmap_item->rmap_list =3D *rmap_list; *rmap_list =3D rmap_item; --=20 2.25.1 From nobody Wed Apr 8 02:51:32 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73660C38145 for ; Wed, 24 Aug 2022 07:08:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233827AbiHXHIe (ORCPT ); Wed, 24 Aug 2022 03:08:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234428AbiHXHIc (ORCPT ); Wed, 24 Aug 2022 03:08:32 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABBF392F73; Wed, 24 Aug 2022 00:08:27 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id 83so9940456pfw.6; Wed, 24 Aug 2022 00:08:27 -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; bh=C9ysgA8b1YgCBIvEexgqiQq6OdwO0KDUjA0c2BYGnmA=; b=LEEMGQDs4/g59g9kDUdIuPraqbT+/kClJ8jAWK7HzkvrxU/dqKEUb0RDp/+CpxB66Y 3lCtmtIwLBpblH9Wjcjt7xvfpfOdXVIGHNBqpC5fiKiURR+vNyU+h2GkTeTLrClT69Mj UR7k+RkuheEe/W1EPL80oMbF7pczj7/zvN9htxsvmBi2hynsUwL7tmb3sHwhgK6G1zAO XSLOBK7t02VBHAOGHL55R6Gz1f2zjZw+DvudGfmyeN6I2oF+LDLJB5q9Vn1Y8+2PIxxF eataJ1qMgMdzAxciIS61HSYj02dBib4Ibq3Jl3kETnCP91qSi43T3UJs6selWo9VSudR /g5A== 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; bh=C9ysgA8b1YgCBIvEexgqiQq6OdwO0KDUjA0c2BYGnmA=; b=K9k0UVRHITql9F2GaYXWqjeGiCkOFLBfaBWy69Db9ge08YeKZH+u8WRU1bFk3rX2ZI WC3HFAJPDrO1p4j5IZ+mZSUUOf3xunNqJKJt9cESIMu2cRf9cZCys/pSnINbwrQEMjN7 8zY9OWeFVEJ40sHjz6De62K33DGSzd3zKJKK6g0qXaf4pK/y7eSTnL59m6mzSxz0O+Hn dG/+7pxMdw0QZeBtRQkiJjuHFVh8/8tliVU2o4Vsv86LRqJMjryUjqDkmgmGGMp4fsZt JdG9jm4j8Q1FavvTqASyWbA8czqYBo26GAm44ZQCWcJe+67JFPNPsCxuUeg13KfBTC64 KEEA== X-Gm-Message-State: ACgBeo0XjBTDGJRLcLPNTwqPDlIBA8FVqyze/tdfyi5VvDA1typlELaT dsMrJatJTn2QhMG94K/0bb4= X-Google-Smtp-Source: AA6agR50+EL5onhLdSLsvcV3vYXXL6Et8CPOgYqocPpC7tATpo1aqiWNYcQDHNDkTpbWlqQhAwkEHQ== X-Received: by 2002:a05:6a00:1588:b0:52f:a5bb:b992 with SMTP id u8-20020a056a00158800b0052fa5bbb992mr28066493pfk.38.1661324907176; Wed, 24 Aug 2022 00:08:27 -0700 (PDT) Received: from localhost.localdomain ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id l9-20020a170902f68900b0016be96e07d1sm11654373plg.121.2022.08.24.00.08.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 00:08:26 -0700 (PDT) From: xu xin X-Google-Original-From: xu xin To: akpm@linux-foundation.org, corbet@lwn.net Cc: bagasdotme@gmail.com, adobriyan@gmail.com, willy@infradead.org, hughd@google.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, xu xin , Xiaokai Ran , Yang Yang Subject: [PATCH v3 2/2] ksm: add profit monitoring documentation Date: Wed, 24 Aug 2022 07:08:21 +0000 Message-Id: <20220824070821.220092-1-xu.xin16@zte.com.cn> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220824070559.219977-1-xu.xin16@zte.com.cn> References: <20220824070559.219977-1-xu.xin16@zte.com.cn> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Add the description of KSM profit and how to determine it separately in system-wide range and inner a single process. Signed-off-by: xu xin Reviewed-by: Xiaokai Ran Reviewed-by: Yang Yang --- Documentation/admin-guide/mm/ksm.rst | 36 ++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-gui= de/mm/ksm.rst index b244f0202a03..40bc11f6fa15 100644 --- a/Documentation/admin-guide/mm/ksm.rst +++ b/Documentation/admin-guide/mm/ksm.rst @@ -184,6 +184,42 @@ The maximum possible ``pages_sharing/pages_shared`` ra= tio is limited by the ``max_page_sharing`` tunable. To increase the ratio ``max_page_sharing`` m= ust be increased accordingly. =20 +Monitoring KSM profit +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +KSM can save memory by merging identical pages, but also can consume +additional memory, because it needs to generate a number of rmap_items to +save each scanned page's brief rmap information. Some of these pages may +be merged, but some may not be abled to be merged after being checked +several times, which are unprofitable memory consumed. + +1) How to determine whether KSM save memory or consume memory in system-wi= de +range? Here is a simple approximate calculation for reference: + + general_profit =3D~ pages_sharing * sizeof(page) - (all_rmap_items) * + sizeof(rmap_item); + +where all_rmap_items can be easily obtained by summing ``pages_sharing``, +``pages_shared``, ``pages_unshared`` and ``pages_volatile``. + +2) The KSM profit inner a single process can be similarly obtained by the +following approximate calculation: + + process_profit =3D~ ksm_merging_sharing * sizeof(page) - + ksm_rmp_items * sizeof(rmap_item). + +where both ksm_merging_sharing and ksm_rmp_items are shown under the direc= tory +``/proc//``. + +From the perspective of application, a high ratio of ``ksm_rmp_items`` to +``ksm_merging_sharing`` means a bad madvise-applied policy, so developers = or +administrators have to rethink how to change madvise policy. Giving an exa= mple +for reference, a page's size is usually 4K, and the rmap_item's size is +separately 32B on 32-bit CPU architecture and 64B on 64-bit CPU architectu= re. +so if the ``ksm_rmp_items/ksm_merging_sharing`` ratio exceeds 64 on 64-bit= CPU +or exceeds 128 on 32-bit CPU, then the app's madvise policy should be drop= ped, +because the ksm profit is approximately zero or negative. + Monitoring KSM events =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --=20 2.25.1