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 BA9ABC3ABC0 for ; Thu, 8 May 2025 18:56:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAE416B00A2; Thu, 8 May 2025 14:56:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5F256B00A3; Thu, 8 May 2025 14:56:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94A7F6B00A4; Thu, 8 May 2025 14:56:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7C90D6B00A2 for ; Thu, 8 May 2025 14:56:44 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B1FC01A0EFF for ; Thu, 8 May 2025 18:56:44 +0000 (UTC) X-FDA: 83420647128.23.D1D005D Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf07.hostedemail.com (Postfix) with ESMTP id 0371B4000D for ; Thu, 8 May 2025 18:56:42 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=pTYr4bSE; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf07.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746730603; a=rsa-sha256; cv=none; b=dVQG8d/Tc1HgulIQvLoCJ2325HFPbFdQ8Z9aldXX2t7HOEWExYpDL9ckcqRPnk/xefve3h hGEyqdlVLSpz678nfLG+aBw3zXiqKCk8PNsYNCgenAfI4qmDHVx30h/jWxyiH9E5XRvb66 ioTj+XjrsLW96XyQ988/exsgJXA/YyU= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=pTYr4bSE; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf07.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746730603; 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:dkim-signature; bh=MMmfDH4IRv0kSMYYEeSF7wbuv8V83KA7+nWbg4KkXT4=; b=R740bFh0U3TPR2PZUh2gg81yr+f5SpIFVrRZvL8IYtlecAk92gp5AO8hClYGkTZCJCIFEW tijbTu9BIWJQb8xGs/LaWVmVHWZht2w0WPoPPrzDMfnWBLGpaVai4FwoiIr6ZY25M2IKQj i2+HrD38+wGdHUixGfCh5XBTq3aQXSM= Date: Thu, 8 May 2025 11:56:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1746730600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MMmfDH4IRv0kSMYYEeSF7wbuv8V83KA7+nWbg4KkXT4=; b=pTYr4bSED8CWaDlWFYtkvE85WC0AnXNvsThBZDvtZ3EcOG8KTVp33GDvSkvAyiq3OPM2tQ jUoiy2JG4e1Ym+7KcyIEwAJtNdGISOf9RfJH4cBHlpeCPGKfnaf5l6+r2QTcYGuZM60mbx 3XNUJY9CNrom+Y+1sqVGLydoB7C5Ujc= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: xu.xin16@zte.com.cn Cc: akpm@linux-foundation.org, david@redhat.com, linux-kernel@vger.kernel.org, wang.yaxin@zte.com.cn, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, yang.yang29@zte.com.cn Subject: Re: [PATCH v2 0/9] support ksm_stat showing at cgroup level Message-ID: References: <20250506130925568unpXQ7vLOEaRX4iDWSow2@zte.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250506130925568unpXQ7vLOEaRX4iDWSow2@zte.com.cn> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0371B4000D X-Stat-Signature: hsx3pg3ajanbtahjbm4ruyoete599quu X-Rspam-User: X-HE-Tag: 1746730602-538027 X-HE-Meta: U2FsdGVkX19Hs+K8n+dlwiyoGhPZ0G4AG903z1NFo9BVpd9B9B78oKpQYbbMRISgaNRhYCYaMudkwIlHbCNtnJBwBy8Ncd7iiOdFuz+RLrLjLDXNpSVie7x3RhWrbhsLtq6GOLxr0Ik8y0iKQJd4klt3SgRg7i9zfOVFSC1oEp/n3ibjh7I0X19FDnNijI+an9ZWxHQmG6o8va6BbNYYeIw/iFaf0NXMos2dDk+M7XqaDEiihhwBog9R8U6yt4CdTO7yfa8CDjcpvic78t/vW6Sr7pNRMseLxrSccE8XMmdjwewD/oVq5ppSCG9YRob4bID9BJqvlrcnfT17br6c5aBl4cWMW9icjJ6GsnKs938QsSwhJmn31qTpJge8NIj6ShGrMsJoOgfk7W43nWM9Jk1TSrL74CO/EMZqKlb8HeteRv/SA+YtHqudM85o6vKY1YPZuSd5zLykvB2gi5jFH+0+niI3sx+sjTNEBgOK7sBfDJK+KV+JtI+IpP+M5hLp4xwJvemUEw8o80o38TGWn6nPykUbdh6XnuB7iGEk9aGf3JCtylY26dcUtZ+bPkeLvGa3AQUgwRKiMJVp2gSYXeOWMRXhnXSIzCQE40dEbEA78heN9oD8j32HekwWx1KpTTVvWmKT2/JOwUMk3mKmIr/TARmZKQ6ipMaaQRfbbaatYBTFRc/N4L7EyJK8e86b+6Zhm4LQe1ovEmIuEu1lHgBf4GiIKQQwWjv6b9AygVQL67BssIEjMVicYGzAtuK90pxOZ2gLCsnGOXAaeL/SLW3g9gtVdLysiPA0zE3HlbiPeej6CbpESPFIZKHB2xFvPld2nMJmbjTyZld0TLE6wxBLzNz0zxrCwfgiv839X2/QZ79/t3au+Wn6CPmbG8x7cr8YooioeuVjTpzgJvJGVAjZv+itkyAs 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: On Tue, May 06, 2025 at 01:09:25PM +0800, xu.xin16@zte.com.cn wrote: > > > 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.