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 7A87EC3ABAC for ; Tue, 6 May 2025 05:09:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4585C6B0085; Tue, 6 May 2025 01:09:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 406B66B0088; Tue, 6 May 2025 01:09:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F4A86B0089; Tue, 6 May 2025 01:09:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 137286B0085 for ; Tue, 6 May 2025 01:09:44 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 65F77121830 for ; Tue, 6 May 2025 05:09:44 +0000 (UTC) X-FDA: 83411305488.12.42AC6DA Received: from mxct.zte.com.cn (mxct.zte.com.cn [183.62.165.209]) by imf06.hostedemail.com (Postfix) with ESMTP id B925618000E for ; Tue, 6 May 2025 05:09:38 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf06.hostedemail.com: domain of xu.xin16@zte.com.cn designates 183.62.165.209 as permitted sender) smtp.mailfrom=xu.xin16@zte.com.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746508182; 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=4zbvd6FCyxaOl24YhezE3SR/jCQOhZfNJ0JpCUDmLPo=; b=qxoeunlPULjMBJPKFhh4ksZhaHt0OAaXYh6jSSVhyE5E7ucbixDfUP9Xf+HSfB+Kbny65w IpwWwVP0/9xCI0uXLvkdxYW52xQJCRs2v6YTaChXTSCTrQ07ig3BN0Q88g57t1gAADOlzQ WZZIy8qRjDs5VUHoioSWZTCtfWXJ9ZA= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf06.hostedemail.com: domain of xu.xin16@zte.com.cn designates 183.62.165.209 as permitted sender) smtp.mailfrom=xu.xin16@zte.com.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746508182; a=rsa-sha256; cv=none; b=aIJUB/P7UKq0+kUzPGHaQ72VYhbrlQdc0urayVm5rS8acTJpyPsDBuVXCCLWR/JLM1BCOR jJNGRSLP+/vxaBLwwDKUsZPekAUs1raj7SOSd1y2/DVgaGICLvXsuk5HyAq2r1cF85O9F7 90nTaOnutsxoH/fwX8P+E9rN9wW31qI= 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 4Zs5zX2C74z4x5rs; Tue, 6 May 2025 13:09:28 +0800 (CST) Received: from xaxapp04.zte.com.cn ([10.99.98.157]) by mse-fl1.zte.com.cn with SMTP id 54659NaT042159; Tue, 6 May 2025 13:09:23 +0800 (+08) (envelope-from xu.xin16@zte.com.cn) Received: from mapi (xaxapp04[null]) by mapi (Zmail) with MAPI id mid32; Tue, 6 May 2025 13:09:25 +0800 (CST) Date: Tue, 6 May 2025 13:09:25 +0800 (CST) X-Zmail-TransId: 2afb68199985284-2afe3 X-Mailer: Zmail v1.0 Message-ID: <20250506130925568unpXQ7vLOEaRX4iDWSow2@zte.com.cn> In-Reply-To: References: 20250501120854885LyBCW0syCGojqnJ8crLVl@zte.com.cn,ir2s6sqi6hrbz7ghmfngbif6fbgmswhqdljlntesurfl2xvmmv@yp3w2lqyipb5 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 54659NaT042159 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 68199988.000/4Zs5zX2C74z4x5rs X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B925618000E X-Stat-Signature: pzjdjc93dijrz5eobqmucnqafeyddhyo X-HE-Tag: 1746508178-186646 X-HE-Meta: U2FsdGVkX1/X7DPMbF3IByS/XsKWooEYvgo57QHt1WUN+6zkuZrsYD00iQ5NVvFKgdnw+ryDg+k0w2h8mEHsk/4RDK9mbrme1DSW6of1hVC7RPopzwoYd1+f02dfx90cnptFIMHREKvL2C1v67zY2GIYn/Hejhskd281rx0rzQiZH2xEOekMTASCPOd1DFAbza8qYyn9NE3u3Fny7hklDj8dgmiQ+c5qEy5uWKMCDbCy+r05Kmf6tlpHN7er9CsWAsnOuJcilP0q/6BJCRhZsepjG331RHDk0vHpVx240VacLbncTHl3JfV6Z248S3T7NQSvWOKCDD9QHyVNlLndu31+aUsXKXNgQ3k1IAs8Q8fyxg3DPoPUri/zidUa14L/aEQBqewO/HRAFFpuhQ3sJ5mFrC6Ak9XCCaYdejTrwZE6Em16d7xKmv8E7O7nXWUGA2548ncuk17EDxNO6xNTbT0OHdYYPe82RQLWFqS18kYnwOcW7mCKOUL909gynzBxEQ2PeNEAz8FF5JxkH+C82znsQrOMZ9lcy9lhjQpkcRtYXvt1oBky9UIXbKi45P6VscT/rOm7ENIuyF7Y0KZOCxX9KwfsBjomCnw5m6qMfX7EG3xAC4/8Y8i56zdLrtPDODy/IBc+cOEyAksd6mh3I8LVR1yAJnH22ix6yokEj742MlIHgKQGbGiL+y2GG/DSzSF6bflbaP4x1vpXLY7d2o4eOupA9eXxRDWjZPZcTnL7lSR1KG8RiFahdezVAQHpiwVGa/3Ieo/iGuT6xfIr1kspERhbqoA1cKZJoIvhJWyuprRhd46JciYocQVt3oQdr40TFjd8vgb0MuOmATqsOyxN6wMN3JGHlGvRIDVndt++2WEu8szbz2zguIdy5jW6NDOt4M3NfFu0oW232QxyoWzBxA0KBveDfQs0jshtObxhQwKhQz5pQdRRx56fI1jMe49a6xyi1uFg8zN4bqk jp38RU4c u77p9jXc/61QLgajMEnEYNsdDFXkHtCnAt8+oTQdBnYYXfr5FQqgApOE17wexKUavikJlfel5PIyS23ewXzkidfqSSsYoxORZLdZauaHURe43FJ61SF/qG5YHiFz+/JLwElYt6/IXXM7R8yKZQ9ySLU2JCb/3NSSBdwtdF/ywme+d3GhXCiiEYc2e2RnDWsoH3KSKS88MOh++fp0= 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. 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. 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.