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 C515DC02180 for ; Mon, 13 Jan 2025 18:39:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FB3D6B0099; Mon, 13 Jan 2025 13:39:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AA636B009C; Mon, 13 Jan 2025 13:39:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 499846B009F; Mon, 13 Jan 2025 13:39:10 -0500 (EST) 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 2948B6B0099 for ; Mon, 13 Jan 2025 13:39:10 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CADACAE7D9 for ; Mon, 13 Jan 2025 18:39:09 +0000 (UTC) X-FDA: 83003290818.09.0A97B07 Received: from out-187.mta0.migadu.com (out-187.mta0.migadu.com [91.218.175.187]) by imf24.hostedemail.com (Postfix) with ESMTP id 05633180005 for ; Mon, 13 Jan 2025 18:39:07 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vFFqsvbG; spf=pass (imf24.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736793548; 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=o/UCRhXYVzb80u83dwZDEreXYoPVjDV1NMvAkaKNMOI=; b=FG63iV4hnFP23HQNUyTwMyzG/AlcGvriFrNkjl4jScqU2tYojY8r2m08WBI/K7ComO906o JL6HiVk+8VOyIgSs2my8M8VXAlxJODDI6ZTWLQZ3rAafObmfun6cEXTd+Sl8DXtvBrZwdQ tatnKdnT9bU/fVXG23B+ISDwinynieY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736793548; a=rsa-sha256; cv=none; b=Fktw6M5Paa1VAwvL6nsLIMZT5td5Q+CYfjgyAgtv8hghvlli7PANa5b+uTayDrfjOvpHgX OWWo1vPuR6pt0y7uzLZsLL+/zqW7/avyb0A8O0AxD6UiqgJLj9o7HUSGiCwNPw+MslnXCa BYGZqhSm2feqe0MigoruqW2hbnzKO7c= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vFFqsvbG; spf=pass (imf24.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Mon, 13 Jan 2025 10:39:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1736793546; 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=o/UCRhXYVzb80u83dwZDEreXYoPVjDV1NMvAkaKNMOI=; b=vFFqsvbGctLEamklCXfzXi0+GDouo+92NWGi2b8zErWxR0JTEzlkaQvgD/hWRrk0o8TZZM cRW2g76edbLorBBqIvo8NPFVzl7bsaczsoDlKQpolsp6MaCBP7wdxJ5hk1JK5ZpMoW6PUl 0EKtk1OV3l4VweZljPFExsy8+sxkF3s= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Tejun Heo Cc: JP Kobryn , mhocko@kernel.org, hannes@cmpxchg.org, yosryahmed@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, cgroups@vger.kernel.org Subject: Re: [RFC PATCH 0/9 v2] cgroup: separate per-subsystem rstat trees Message-ID: References: <20250103015020.78547-1-inwardvessel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 05633180005 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: 7fpuzr9gdze61yq897jo9anw6kxq7q7b X-HE-Tag: 1736793547-613914 X-HE-Meta: U2FsdGVkX19r2/20Fjb+McXBlcAAU4CaUiN+K03JPQo5NanJpd1UQjQNItWwq/mAC4JsT9Ia+QvT6ToXgcpLNk+68AaV+AlPPlyKMwqwT/UomELHy0/vdmG2dBVuD29ViD3FZoXxNFO6QQB75+Q3Gq4VYZYPWt4RtM6RllQsKuukRQ3W4tMPoFTs8CwjEQ5U7E6/kiHdCNj+u35NYo1sLXhP2rirJPYjwIYEBGdfoNz0bUK/rzk/dm5enU0uUdPbiDmPPuPeAOA/K++Wjro3fGjV2+5LxkIS93gAIxDj8VLuSvAl9qe48xDQBRBxzCOMNtOqDz9E2rKHDdSQYRenp2g3VNU7Mhp+PgfvyO+2WSRUBo9VI+E53wX8XH/Rrx7sr7EnDDBBPbKEc2Yfv5O7XTDSfoZME9QiugmzGuV858e41u+ysnmjwN6TSMWr+6OHpUoNWUNtf99kIg8N0z96yXpl6t3ZIJdE8Oy4tzE3nZcfjSN1hH0UAi4MzrUU4Su4AQf6i6ESbN7YxD99aavBvZBZr0GYqOXzM+f1FOL0dF7diGuPdnJ9hFFYPuSILXVaDSukP8OIeeop2Tj0HGY9vLP36E2axnuJx6kuo/iJf06kECTfrEtv+4xxiDCm2GzOsnV2ViHJjwaWFLffPg2s+C81fpsy1oniBEIAN6Q6BqdB5RaPSmB62S7SD67OSpD7UCLTWJgvY/iTLgBk1hxpVaM9mTOC/VodSc9kIeM78egqN/ImdZDQGKTvxkfRLULjTZnsJEvuuvLUX8LFvLtMAzwHWFCQjZMdRCj6qHBShMn6sAS+eLb8msPGW9hIEfNOKmc5eBng7kpH3QhVrvxKAXzceaBpoCq7Ufice+irPbivNvPBCZtL6TPBMh/liix1Wiy7nkkGHncBsMsQSF+kS7eQ8kyeqKZelkXnegDW5UPCju5KaEszXgU8f37ecWjM1LlIU7IBOpSXqYbnGhe zL69URX3 OkYvYwQRAnG5SD8XjNxALYWocyqqGxjCGjL5u/3bjd5y9+NHZ5YgJ+htnp8bHCf2j3kQeF6FpqshXcdyS4BxxpWtre1+5OoKTijmoWSHShH6TeceV31Mz97RPIdmPwkvh9JNdAHavHO+4HAynJY/ck0KGzQ== 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 Fri, Jan 03, 2025 at 12:08:39PM -1000, Tejun Heo wrote: > Hello, > > On Thu, Jan 02, 2025 at 05:50:11PM -0800, JP Kobryn wrote: > ... > > I reached a point where this started to feel stable in my local testing, so I > > wanted to share and get feedback on this approach. > > The rationale for using one tree to track all subsystems was that if one > subsys has been active (e.g. memory), it's likely that other subsyses have > been active too (e.g. cpu) and thus we might as well flush the whole thing > together. The approach can be useful for reducing the amount of work done > when e.g. there are a lot of cgroups which are only active periodically but > has drawbacks when one subsystem's stats are read a lot more actively than > others as you pointed out. I wanted to add two more points to above: (1) One subsystem (memory) has in-kernel stats consumer with strict latency/performance requirement and (2) the flush cost of memory stats have drastically increased due to more than 100 stats it has to maintain. > > Intuitions go only so far and it's difficult to judge whether splitting the > trees would be a good idea without data. Can you please provide some > numbers along with rationales for the test setups? Here I think the supportive data we can show is the (1) non-memory stats readers not needing to spend time on memory stats flushing and (2) with per-subsystem update tree, have we increased the cost of update tree insertion in general? Anything else you think will be needed? Thanks Tejun for taking a look.