On Fri, 14.11.14 20:36, Lutz Vieweg ([email protected]) wrote: > 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. > > 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 -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
