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 17FDFC54FB3 for ; Mon, 2 Jun 2025 14:15:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F6FC6B02A0; Mon, 2 Jun 2025 10:15:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CE786B02A1; Mon, 2 Jun 2025 10:15:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 40B5A6B02A2; Mon, 2 Jun 2025 10:15:10 -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 1ED476B02A0 for ; Mon, 2 Jun 2025 10:15:10 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 77CE0C099A for ; Mon, 2 Jun 2025 14:15:09 +0000 (UTC) X-FDA: 83510657538.15.C38F114 Received: from mxct.zte.com.cn (mxct.zte.com.cn [183.62.165.209]) by imf08.hostedemail.com (Postfix) with ESMTP id 4A590160018 for ; Mon, 2 Jun 2025 14:15:05 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of xu.xin16@zte.com.cn designates 183.62.165.209 as permitted sender) smtp.mailfrom=xu.xin16@zte.com.cn; dmarc=pass (policy=none) header.from=zte.com.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748873707; a=rsa-sha256; cv=none; b=7m0L5l9uLKLTbcWVKFKqusYehGMt7oPK95xAy0sbnMowSEXcAlj8xU4CQxlES5pFlqnxMz dcvmZqkoEnHxp5/Q+7HbNYaohUaz1mws48SzxXpK/YoOt7dDvLNt+0S15R7cv2SIIOLN3V z0YnPPhWzEFKd0I+iIy82VBEQKnxqN0= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of xu.xin16@zte.com.cn designates 183.62.165.209 as permitted sender) smtp.mailfrom=xu.xin16@zte.com.cn; dmarc=pass (policy=none) header.from=zte.com.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748873707; 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:in-reply-to:references:references; bh=aM849Vt9kph9jqxeXKfm5pxFEwBPhhpoRLMRft17Q3Y=; b=mimpWwp597HmHdgRhQZRJm97Jkds/J3bgxgTa1FHAiVVKRc6aewDlUiEJny0N/R+HcBHqP dJZ4ukGZL/Wh+TqWK1pjbP1dnkHinmI37sN9LINbDUE2dhMLlACF48BnERXm7UCL+WG/Di KwMaroOJc+bcY5MSnok33GaHM8mA9TU= 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 mxct.zte.com.cn (FangMail) with ESMTPS id 4b9wpT574Dz52SGw; Mon, 2 Jun 2025 22:14:57 +0800 (CST) Received: from xaxapp04.zte.com.cn ([10.99.98.157]) by mse-fl1.zte.com.cn with SMTP id 552EEsEb075609; Mon, 2 Jun 2025 22:14:54 +0800 (+08) (envelope-from xu.xin16@zte.com.cn) Received: from mapi (xaxapp01[null]) by mapi (Zmail) with MAPI id mid32; Mon, 2 Jun 2025 22:14:58 +0800 (CST) Date: Mon, 2 Jun 2025 22:14:58 +0800 (CST) X-Zmail-TransId: 2af9683db1e25dc-fe1e1 X-Mailer: Zmail v1.0 Message-ID: <20250602221458798de-eCxDE3QgOIkg0WG1nB@zte.com.cn> In-Reply-To: References: ir2s6sqi6hrbz7ghmfngbif6fbgmswhqdljlntesurfl2xvmmv@yp3w2lqyipb5,20250506130925568unpXQ7vLOEaRX4iDWSow2@zte.com.cn,t7q2d73nxdd75sghobnpmzi7bsbvden6lbrtejkxyoqfl2xilv@4ewvm2od2sf3 Mime-Version: 1.0 From: To: Cc: , , , , , , Subject: =?UTF-8?B?UmU6IFtQQVRDSCB2MiAwLzldIHN1cHBvcnQga3NtX3N0YXQgc2hvd2luZyBhdCBjZ3JvdXAgbGV2ZWw=?= Content-Type: text/plain; charset="UTF-8" X-MAIL:mse-fl1.zte.com.cn 552EEsEb075609 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 683DB1E1.001/4b9wpT574Dz52SGw X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4A590160018 X-Stat-Signature: hoy6ko1hji6w9t1wmc48jb8ps85yh9qe X-Rspam-User: X-HE-Tag: 1748873705-721284 X-HE-Meta: U2FsdGVkX19oLHEZhAaeYJPkbRY8NYkDVLRGngFKi+Lj9dZZKEnxO7rgLQOs4Y1b3OciRLxnE60rm2wQ8gAi8d8Wfr7pxTTMFBLgP9YDb4m5H8393GdOmT+rpk0g1Aj6MiMr/rMocs6MEVMRKRbZ4E/O/X1Eo/MGQ/OKdGqCBmWEzzM9IkX3nXV4sMlKVuwony9wjWto3giJLGMk6VZa2h0q3KspV+O3PA0qvB7b7sG/tTdnKa1U20n6W/frKRKHcCO4OwP2h4XQtawjw25c+qVI05HifqFm5jlus1RQbzHjNHeanqQxSldqimrBjB4y+aR78VC6jLvOoQnVg+C+ygzcsSanXZ6yce3xSKiXymUICId1VX2e4IPxLX8Fu96vIy4wZq4/T474nSZ00/ksXfwj+uV23wj450MAUK1vcaMr4NOsd5PFIliIli1LCaNTcc2PBDtVhtcftUlIX6CzvBgQiUX6FQ1NooWC12XMhThVYkxCUoxmVskx7YN42nqRMaGsRkBvtNprwiEZAVpPqXjxGoE/j3UTMqbEY1RQFtn3N5zUPrg+kHhnxyeA5Qgxg8SBYpk1HNM2K+uYpJJZGyOzZ0zkBg5hOrQYH1OSLw2blNG7GHxWNHtk265CSY6WOzC8FhSyhvmVOy0da12IwYUtSie/oxrIJtL56jLI9wo+vMMShxXAShTmW/HcuGPTfuamabFLiR5M7+guCWM9bGW0f0oPqK+nCSIQFF6Apc1vfAk7+Wwv3O3OrsXXXnjLvay452Woy7kJ86BfJXoeGgo4wOLsCb+PVfFpqyeEoWVNWyD+kzS9zKohlbe0DE53hA5ZJDWlCwGZn3D3BBkc/6TGd5klvb5ptcnoJx4lY5pdrUUK4IubU8dlF5iOUQLRZgnM8ezsLiWNissmCDJyBYY6n+2s/DbAJLzKZC3Eo5CK4jYdVxI9+3WUKDcU2Wd9GegEUQOqIe4uxjWPqHm kNNhlln1 R44WQEBJHwKjXv2TTaB7RbycZGVBaNAhzhxj8oRzOLvE+CvsyHUZZC9iMbnTc3KjoQbAPR7+sVRFOnVj/uRaX4tJwhJR/ay/b/o3v1YVcyih+/HgcbGqw7T0DUodHT+oSy0cjFt0ODDQv2P7EBabb9g7eRBLEL0I3wXL8e3RKsQlni9O0c6WZjegrZvm/YTBXRksWy+YajprHbfFuLEBuGkYxJ4eklOmli7t+9LmJdbzgTJGtreYEPtRs4U2c5MqE2BKfFSM0743/m/eFWd1ZnFidpA== 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: List-Subscribe: List-Unsubscribe: > > > > Users can obtain the KSM information of a cgroup just by: > > > > > > > > # cat /sys/fs/cgroup/memory.ksm_stat > > > > ksm_rmap_items 76800 > > > > ksm_zero_pages 0 > > > > ksm_merging_pages 76800 > > > > ksm_process_profit 309657600 > > > > > > > > Current implementation supports both cgroup v2 and cgroup v1. > > > > > > > > > > Before adding these stats to memcg, add global stats for them in > > > enum node_stat_item and then you can expose them in memcg through > > > memory.stat instead of a new interface. > > > > Dear shakeel.butt, > > > > If adding these ksm-related items to enum node_stat_item and bringing extra counters-updating > > code like __lruvec_stat_add_folio()... embedded into KSM procudure, it increases extra > > CPU-consuming while normal KSM procedures happen. > > How is it more expensive than traversing all processes? > __lruvec_stat_add_folio() and related functions are already called in many > performance critical code paths, so I don't see any issue to call in the > ksm. > > > Or, we can just traversal all processes of > > this memcg and sum their ksm'counters like the current patche set implmentation. > > > > If only including a single "KSM merged pages" entry in memory.stat, I think it is reasonable as > > it reflects this memcg's KSM page count. However, adding the other three KSM-related metrics is > > less advisable since they are strongly coupled with KSM internals and would primarily interest > > users monitoring KSM-specific behavior. > > We can discuss and decide each individual ksm stat if it makes sense to > added to memcg or not. > > > > > Last but not least, the rationale for adding a ksm_stat entry to memcg also lies in maintaining > > structural consistency with the existing /proc//ksm_stat interface. > > Sorry, I don't agree with this rationale. This is a separate interface > and can be different from exisiting ksm interface. We can define however > we think is right way to do for memcg and yes there can be stats overlap > with older interface. > > For now I would say start with the ksm metrics that are appropriate to > be exposed globally and then we can see if those are fine for memcg as > well. Thank you very much for your suggestion, and I'm sorry for the delayed reply as last month I was exceptionally busy. Upon further consideration, I agree that adding entries to the existing memory.stat interface is indeed preferable to arbitrarily creating new interfaces. Therefore, my next step is to plan adding the following global KSM metrics to memory.stat, such as ksm_merged, ksm_unmergable, ksm_zero, and ksm_profit. (These represent the total amount of merged pages, unmergable pages, zero pages merged by KSM, and the overall profit, respectively.) However, please note that ksm_merging_pages and ksm_unshared need to be converted to be represented in bytes.”