[systemd-devel] systemd-cgtop memory utilization display not useful

[Lutz Vieweg]

Hi,

I noticed that systemd-cgtop in the "memory" column
displays (and uses for sorting) a value that does include
the cache memory somehow attributed to the slice.

This makes little sense, as

a) cache memory is freed when a task requires that
memory for more important purposes, so cache memory
utilization never causes OOM-kills to happen

b) it causes usage numbers to be displayed that are
way beyond the memory.limit_in_bytes, because the
kernel (for good reason) does utilize more memory
for caching than what is limited by memory.limit_in_bytes

c) the sorting by "biggest memory user" is weird if
a slice is sorted first that might contain not a single
task, but which was associated with a recently running
task that read some 8 GB file, while another slice
containing a permanently running task that allocates
7 GB of RAM is sorted thereafter.

Please reconsider what values systemd-cgtop uses,
"rss" and "rss-huge" from "memory.stat" might be better
candidates than the currently used.

Regards,

Lutz Vieweg

[Lennart Poettering]

Post by Lutz Vieweg
Hi,
I noticed that systemd-cgtop in the "memory" column
displays (and uses for sorting) a value that does include
the cache memory somehow attributed to the slice.

We use the "memory.usage_in_bytes" value as exposed by the memory
cgroup controller. I think the kernel cgroup maintainers are aware
that it is currently not ideal, and are revisiting what they export
there.

Post by Lutz Vieweg
This makes little sense, as
a) cache memory is freed when a task requires that
memory for more important purposes, so cache memory
utilization never causes OOM-kills to happen
b) it causes usage numbers to be displayed that are
way beyond the memory.limit_in_bytes, because the
kernel (for good reason) does utilize more memory
for caching than what is limited by memory.limit_in_bytes
c) the sorting by "biggest memory user" is weird if
a slice is sorted first that might contain not a single
task, but which was associated with a recently running
task that read some 8 GB file, while another slice
containing a permanently running task that allocates
7 GB of RAM is sorted thereafter.
Please reconsider what values systemd-cgtop uses,
"rss" and "rss-huge" from "memory.stat" might be better
candidates than the currently used.

Last time I talked about this with Tejun he suggested sticking with
the current attribute, but that the kernel folks would change would it
would actually report to a more useful value.

Lennart