From: Tejun Heo <tj@kernel.org>
To: JP Kobryn <inwardvessel@gmail.com>
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
Date: Thu, 20 Mar 2025 11:44:19 -1000 [thread overview]
Message-ID: <Z9yMMzDo6L7GYGec@slm.duckdns.org> (raw)
In-Reply-To: <20250319222150.71813-5-inwardvessel@gmail.com>
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
next prev parent reply other threads:[~2025-03-20 21:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 22:21 [PATCH 0/4 v3] cgroup: separate rstat trees JP Kobryn
2025-03-19 22:21 ` [PATCH 1/4 v3] cgroup: use separate rstat api for bpf programs JP Kobryn
2025-03-24 17:47 ` Michal Koutný
2025-03-25 18:03 ` JP Kobryn
2025-03-26 0:39 ` Yosry Ahmed
2025-03-19 22:21 ` [PATCH 2/4 v3] cgroup: use separate rstat trees for each subsystem JP Kobryn
2025-03-20 21:31 ` Tejun Heo
2025-03-21 17:22 ` JP Kobryn
2025-03-24 17:48 ` Michal Koutný
2025-03-19 22:21 ` [PATCH 3/4 v3] cgroup: use subsystem-specific rstat locks to avoid contention JP Kobryn
2025-03-20 21:38 ` Tejun Heo
2025-03-24 17:48 ` Michal Koutný
2025-03-19 22:21 ` [PATCH 4/4 v3] cgroup: save memory by splitting cgroup_rstat_cpu into compact and full versions JP Kobryn
2025-03-20 21:44 ` Tejun Heo [this message]
2025-03-21 17:45 ` JP Kobryn
2025-03-24 17:49 ` Michal Koutný
2025-03-25 13:55 ` Shakeel Butt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z9yMMzDo6L7GYGec@slm.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=inwardvessel@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-mm@kvack.org \
--cc=mkoutny@suse.com \
--cc=shakeel.butt@linux.dev \
--cc=yosryahmed@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox