[systemd-devel] Question regarding memory accounting display behavior related to MemoryAccounting
Michal Koutný
mkoutny at suse.com
Thu Nov 7 20:00:35 UTC 2024
Hi Matthew.
On Wed, Oct 02, 2024 at 08:10:04AM GMT, Matthew Chae <Matthew.Chae at axis.com> wrote:
> https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html#MemoryAccounting=
The implicit accounting is from kernel PoV. With the unified cgroup
hierarchy, same granularity applies to all siblings. The notice here to
be aware that even units that not enable it exlicitly would be subject
of possible accounting overhead.
> Here are my questions below.
>
> First, as mentioned above, systemd-cgtop shows memory accounting for
> each service in a slice, even if only one service in the slice has
> MemoryAccounting=yes.
> However, when running "systemctl status", memory accounting is only
> displayed for services with MemoryAccounting=yes, as shown in the
> first image below.
> Other services in the same slice do not display memory accounting, as
> shown in the second image below. Is there any specific reason for this
> behavior? According to the description of MemoryAccounting above,
> shouldn't other services also display memory accounting when running
> "systemctl status"?
I don't think there's a reason, cgtop just reads what it gets from
cgroupfs and it ain't that much involved in config parsing.
Status (and other operations with a particular unit) factor in the
config where explicit accounting implies other features (e.g. OOM
tracking).
> Second, shouldn't systemd-cgtop display not only the value of
> memory.current, like systemctl status does, but also memory.peak,
> which is part of cgroup memory accounting?
This is a feature request, which could likely be accepted in a form of
a patch ;-)
Michal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20241107/fdf59aea/attachment.sig>
More information about the systemd-devel
mailing list