From: Tejun Heo <tj@kernel.org>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>,
hannes@cmpxchg.org, lizefan.x@bytedance.com,
cgroups@vger.kernel.org, longman@redhat.com,
netdev@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, shakeel.butt@linux.dev,
kernel-team@cloudflare.com,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
mhocko@kernel.org, Wei Xu <weixugc@google.com>
Subject: Re: [PATCH v1 3/3] cgroup/rstat: introduce ratelimited rstat flushing
Date: Thu, 18 Apr 2024 11:15:31 -1000 [thread overview]
Message-ID: <ZiGNc6EiuqsTJ2Ry@slm.duckdns.org> (raw)
In-Reply-To: <CAJD7tkbNvo4nDek5HV7rpZRbARE7yc3y=ufVY5WMBkNH6oL4Mw@mail.gmail.com>
Hello, Yosry.
On Thu, Apr 18, 2024 at 02:00:28PM -0700, Yosry Ahmed wrote:
...
> I think this is an artifact of different subsystems sharing the same
> rstat tree for no specific reason. I think almost all flushing calls
> really need the stats from one subsystem after all.
>
> If we have separate trees, lock contention gets slightly better as
> different subsystems do not compete. We can also have different
> subsystems "customize" their trees, for e.g. by setting different
> time-based or magnitude-based rate-limiting thresholds.
>
> I know this is a bigger lift, just thinking out loud :)
I have no objection to separating out rstat trees so that it has
per-controller tracking. However, the high frequency source of updates are
cpu and memory, which tend to fire together, and the only really high
frequency consumer seems to be memory, so I'm not too sure how much benefit
separating the trees out would bring.
Thanks.
--
tejun
next prev parent reply other threads:[~2024-04-18 21:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 17:51 [PATCH v1 0/3] cgroup/rstat: global cgroup_rstat_lock changes Jesper Dangaard Brouer
2024-04-16 17:51 ` [PATCH v1 1/3] cgroup/rstat: add cgroup_rstat_lock helpers and tracepoints Jesper Dangaard Brouer
2024-04-16 21:36 ` Tejun Heo
2024-04-18 8:00 ` Jesper Dangaard Brouer
2024-04-23 16:53 ` Simon Horman
2024-04-29 11:36 ` Jesper Dangaard Brouer
2024-04-29 17:48 ` Simon Horman
2024-04-16 17:51 ` [PATCH v1 2/3] cgroup/rstat: convert cgroup_rstat_lock back to mutex Jesper Dangaard Brouer
2024-04-18 2:19 ` Yosry Ahmed
2024-04-18 9:02 ` Jesper Dangaard Brouer
2024-04-18 14:49 ` Shakeel Butt
2024-04-18 20:39 ` Yosry Ahmed
2024-04-19 13:15 ` Jesper Dangaard Brouer
2024-04-19 16:11 ` Shakeel Butt
2024-04-19 19:21 ` Yosry Ahmed
2024-04-18 20:38 ` Yosry Ahmed
2024-04-16 17:51 ` [PATCH v1 3/3] cgroup/rstat: introduce ratelimited rstat flushing Jesper Dangaard Brouer
2024-04-18 2:21 ` Yosry Ahmed
2024-04-18 11:00 ` Jesper Dangaard Brouer
2024-04-18 15:49 ` Shakeel Butt
2024-04-18 21:00 ` Yosry Ahmed
2024-04-18 21:15 ` Tejun Heo [this message]
2024-04-18 21:22 ` Yosry Ahmed
2024-04-18 21:32 ` Tejun Heo
2024-04-19 10:16 ` Jesper Dangaard Brouer
2024-04-19 19:25 ` Yosry Ahmed
2024-04-16 21:38 ` [PATCH v1 0/3] cgroup/rstat: global cgroup_rstat_lock changes Tejun Heo
2024-04-18 2:13 ` Yosry Ahmed
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=ZiGNc6EiuqsTJ2Ry@slm.duckdns.org \
--to=tj@kernel.org \
--cc=acme@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hawk@kernel.org \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan.x@bytedance.com \
--cc=longman@redhat.com \
--cc=mhocko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=weixugc@google.com \
--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