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 46F85C28B30 for ; Thu, 20 Mar 2025 21:44:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDA97280002; Thu, 20 Mar 2025 17:44:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E615B280001; Thu, 20 Mar 2025 17:44:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D021A280002; Thu, 20 Mar 2025 17:44:22 -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 AEB47280001 for ; Thu, 20 Mar 2025 17:44:22 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4AFD1141947 for ; Thu, 20 Mar 2025 21:44:23 +0000 (UTC) X-FDA: 83243258406.01.5381349 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf19.hostedemail.com (Postfix) with ESMTP id 955DA1A0007 for ; Thu, 20 Mar 2025 21:44:21 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GL4OlvRT; spf=pass (imf19.hostedemail.com: domain of tj@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=tj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742507061; 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=/Ok9wOfl1Wsp0CSX2awSFNRheo9ODPuytDeL1/kqArQ=; b=f2hInQKG3ov0W5jQFLxT628KzeP/xR1+KdzvytDF0XdPvIsEQ+f02LeyF4pjLc6/q1UMHG QgMXESz8AHo728tu3iZtKh3iYE9DGxD7PcMybwLJDpVvdL131tzEyzOt6j04kPI3Gnc4me 8PSttQ8v0J1lUNTUbx4yG747YdQHFaA= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GL4OlvRT; spf=pass (imf19.hostedemail.com: domain of tj@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=tj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742507061; a=rsa-sha256; cv=none; b=qWZ+HoI2OtvtGQDhTadkNqwBJVhnCkEVaZHmk2khI5KpWSnppWjuPK07jZ1qwvLBY+Kz2N GZ84NeueL3FU4pexEz6QlQ5fE3FDFDG2VJO9sJEeK7eZDXfMyWnUF7HSdpe2JhAzqM8zv4 I2bZV9V8G679Vg2OEZd6dJ+6PistHhQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id BDD8343512; Thu, 20 Mar 2025 21:44:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F29BDC4CEDD; Thu, 20 Mar 2025 21:44:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742507060; bh=dH3CJMuNKLt5T1SNjnqbJSVsJQBEkZlz8zbx3AjYlxM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GL4OlvRT9oYrG11Cnp/kikGAgNDKUq/YLMalfuEzGCZ8n9FOgJUz5DjfBymL9ti+h 7N2Pa0ZJRKeINC4VZZ/ud6Hqxaa+0bi4yTxY6Z5ffcWmkty0zhrzQbCNVC14j1uUQ1 a9RAvqyoyGTSJfxN4mXr2SF0tk8oDP6Mm/KWPukTmpvstz4ED0JsPztBpuKUiCTDmz k1/Ex2Kxvuc3ug72B/bB/F/sOD3i0khfEi5qaFXaLdDTRyfEzkZftSyjjE2DLkOCDX naH9HgfcNwzCGDFAfI9RDqGL7aPXpNy8qTO4bbzHIn5OgHexlFvr1qP4lt+fY3yNUj B8QlLhqgeE15Q== Date: Thu, 20 Mar 2025 11:44:19 -1000 From: Tejun Heo To: JP Kobryn Cc: shakeel.butt@linux.dev, yosryahmed@google.com, mkoutny@suse.com, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-mm@kvack.org, cgroups@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH 4/4 v3] cgroup: save memory by splitting cgroup_rstat_cpu into compact and full versions Message-ID: References: <20250319222150.71813-1-inwardvessel@gmail.com> <20250319222150.71813-5-inwardvessel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250319222150.71813-5-inwardvessel@gmail.com> X-Rspamd-Queue-Id: 955DA1A0007 X-Stat-Signature: mu6kbn38do49abbckbmh5b4mzh7akm5e X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1742507061-43050 X-HE-Meta: U2FsdGVkX1/PRcin9N5lW5dJTuPdbLVMlNheKLNC0tYmwKi5I8tJLWMf6XJFj+9jYEUcqV1f20OXYGLpM5wQBs1em3tc/zPa3dNoDnG2ov7iJoz0hLQQwNB7h4oghD54JvHKLTzl68wB0jJL6DvPE8B6yXE6TfIZXEcKcGK7SvKf7IzbPn+U8z64ljGP24c0TGAOG5HKlPPTLtRdhhV4SKu1kZUh3jewBQnzEAaSLFlgWLBxgWqbA6z2QGanNbQLyWo3BxbhaQ+gA8oJbxY/3fubN9kpEdVflQ7bGMBlfU30D3mXGw4PL4WQtDMulSl9Zxql0fQ8WzEXuRKY/b5dC3p/f+ett15fOIn9kH3XblVv04sI9nNb3mW5EzjXLihT04EqLZJ2Zg1XPo9HAuc0dNKC5Kk5RUhD2gAiv/fyLAcJf0b7kh7dAVGKnTPrvW7Dg0GvMZd3Fgbczk9XZXvKsEzi1gIiP5QEdDJupLR8BURCCwVcL5R97NnLR/1eohEOuCLG8rCGE4+9Ce7SIv6k1XdvnZN+pC8b1gnD9bL7Nr+QngUvFc7goEWXvu7Mj+U+6x9Etuc4ftHGjFvMm7GHc6t3IjMMdluB5aEAU7TKiVqCWx90SfvicbmC9894MrkDTU780Am9pK4dnfE+SGakvsHN9Wz5x2qnol5RaNi5LFOINcvFaPgjKK6fvP32miUh6Gl+8bPwnbLzyHHLZzCeqCX89x1FlQBVv+k566MLfmBJeAm1FFuM1ja8dHMS3syHDlXe1c1GEp3QtrXaitd9N3K3R2BdQl9Bg+s22i6rJvGGbRFkI+Nna3p3IxYBE907+Vfj9pgLL57BhsOs2z5TL3OkUO5erf0GTrrfu7p69oOESKGRx7wlahRnbm69PgsAD1T6AxKI7ZuON28BV+EUlBTEHMlqxWXgXc57kggiH2QM5qwH2V5N7qUjwikP3utOzAHlFJqzIXE73MzgVVs /XomEYD3 5D8+soroJ+L0Ll2RYaQy4hEZ5M1lCJR0EZlhWRbuwjFRjvpGJI8CRB0BC17pZT/dU7kvIjLP0ePfNMsfY2cSjAEwbPYGxgOLSRtB7IqQOtp+GBmTm3RAGsA6fCxY7TQnpnkqNwPiSgIqgDStvLWZkYAHgsXYJDOZHgNbs1MDNFnDmCE2UINu/gEN5yMpOYViNiIMMxpsUn6+KhCeGfLUhZJr26LGXbsaK4IcKN5NkcgRVFIojAg9ELrH8ePXwm4gH1lnN 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: Hello, On Wed, Mar 19, 2025 at 03:21:50PM -0700, JP Kobryn wrote: > The cgroup_rstat_cpu struct contains rstat node pointers and also the base > stat objects. Since ownership of the cgroup_rstat_cpu has shifted from > cgroup to cgroup_subsys_state, css's other than cgroup::self are now > carrying along these base stat objects which go unused. Eliminate this > wasted memory by splitting up cgroup_rstat_cpu into two separate structs. > > The cgroup_rstat_cpu struct is modified in a way that it now contains only > the rstat node pointers. css's that are associated with a subsystem > (memory, io) use this compact struct to participate in rstat without the > memory overhead of the base stat objects. > > As for css's represented by cgroup::self, a new cgroup_rstat_base_cpu > struct is introduced. It contains the new compact cgroup_rstat_cpu struct > as its first field followed by the base stat objects. > > Because the rstat pointers exist at the same offset (beginning) in both > structs, cgroup_subsys_state is modified to contain a union of the two > structs. Where css initialization is done, the compact struct is allocated > when the css is associated with a subsystem. When the css is not associated > with a subsystem, the full struct is allocated. The union allows the > existing rstat updated/flush routines to work with any css regardless of > subsystem association. The base stats routines however, were modified to > access the full struct field in the union. Can you do this as a part of prep patch? ie. Move the bstat out of rstat_cpu into the containing cgroup before switching to css based structure? It's rather odd to claim memory saving after bloating it up due to patch sequencing. > diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h > index 0ffc8438c6d9..f9b84e7f718d 100644 > --- a/include/linux/cgroup-defs.h > +++ b/include/linux/cgroup-defs.h > @@ -170,7 +170,10 @@ struct cgroup_subsys_state { > struct percpu_ref refcnt; > > /* per-cpu recursive resource statistics */ > - struct css_rstat_cpu __percpu *rstat_cpu; > + union { > + struct css_rstat_cpu __percpu *rstat_cpu; > + struct css_rstat_base_cpu __percpu *rstat_base_cpu; > + }; I have a bit of difficult time following this. All that bstat is is the counters that the cgroup itself carries regardless of the subsystem but they would be collected and flushed the same way. Wouldn't that mean that the cgroup css should carry the same css_rstat_cpu as other csses but would have separate struct to carry the counters? Why is it multiplexed on css_rstat_cpu? Thanks. -- tejun