[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <uylrr7ajj6qttrcvbout4lhm3lfcepgjm5maizvitnyghjnr2o@xy2hdbgaxyxs>
Date: Fri, 2 May 2025 15:56:23 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Max Kellermann <max.kellermann@...os.com>
Cc: tj@...nel.org, hannes@...xchg.org, cgroups@...r.kernel.org.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kernel/cgroup/pids: add "pids.forks" counter
On Fri, May 02, 2025 at 03:23:26PM +0200, Max Kellermann <max.kellermann@...os.com> wrote:
> Sure you can do everything with BPF, but that's several magnitudes
> more overhead (if you worry about the atomic operation in my patch).
I worried about users that don't need the counter ;-)
> we want to monitor all servers permanently and log every counter of
> every cgroup.
OK, I assumed the process "clock" is only useful transiently for
debugging...
> Later, if we see (performance) problems, we can reconstruct from those
> logs what/who may have caused them. The fork counter is an interesting
> detail for this.
...since it's more of a proxy measure over other cummulative stats that
are bound to actual resources like cpu time or vmstat:pgalloc* [1].
> It's very useful for us and that justifies the (small) memory+atomic
> overhead, but others may have a different opinion. If you don't find
> it useful, we'll just keep the patch in our private kernel fork (like
> dozens of others).
OK, let's see if someone else finds it so useful too. Definitely thanks
for putting it forward as first.
Michal
[1] This is actually something that I find missing for memcgs.
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists