On 07/21/2015 10:48 AM, Michal Hocko wrote: > On Mon 20-07-15 14:22:32, Nikolay Borisov wrote: >> >> >> On 07/20/2015 02:17 PM, Michal Hocko wrote: >>> On Fri 17-07-15 10:16:25, Nikolay Borisov wrote: >>>> >>>> >>>> On 07/17/2015 10:13 AM, Michal Hocko wrote: >>>>> On Fri 17-07-15 00:21:51, Nikolay Borisov wrote: >>> [...] >>>>>> In my particular use case I have to query the memcg's various counters to expose >>>>>> them to the user in a different way than via the cgroup files >>>>>> (memory.limit_in_bytes etc). >>>>> >>>>> Why is the regular interface not sufficient? >>>> >>>> In my particular case I'm interested in playing with the contents of >>>> /proc/meminfo, so that processes running inside a cgroup only see the >>>> the system as defined by the memcg restrictions >>> >>> I assume that this is an attempt to containerize /proc/meminfo. I am not >>> sure this is a great idea. There are counters which do not have memcg >>> specific counterpart or such a counterpart would be missleading (e.g. >>> slab, swap statistics). >> >> Why would swap be misleading? > > Because the swap space is inherently a shared resource. > >> What about memsw.limit_in_bytes - memory.limit_in_bytes for the total swap > > No this is not how the swap extension works. memsw counter covers > usage+swap. You can have up to memsw.limit_in_bytes swapped out. So I think you are wrong with that assumption. According to the documentation here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-memory.html (the box titled "Setting the memory.memsw.limit_in_bytes and memory.limit_in_bytes parameters") it seems that the space that could be swapped is actually memsw.limit_in_bytes - memory.limit_in_bytes. The way I understand is you will only start swapping after the limit in memory.limit_in_bytes has been exhausted and you will be able to swap only until memsw.limit_in_bytes is exhausted (but since memory.usage_in_bytes is already calculated in, which would equal to memory.limit_in_bytes in a memory pressure situation) you effectively have memsw.limit_in_bytes - memory.limit_in_bytes, no? > you would have to do min(memsw.limit_in_bytes, TotalSwap) but even then > it wouldn't tell you much because that would be the case for other > memory cgroups as well. I would be quite hard to distribute the > TotalSwap for all the cgroups. > >> and calculating the swap usage >> based on memory.memsw.max_usage_in_bytes - memory.usage_in_bytes ? > > This doesn't make much sense to me. Swap usage per memcg is exported by > memory.stat file. But this is not what you want to export. meminfo > exports SwapFree which would tell you how much memory could be swapped > out before the anonymous memory is not reclaimable anymore. This is > impossible to find out in general - especially when the system is > allowed to be overcommit. I looked more carefully into the code and saw that the page_counters (which back memory/memsw.limit/usage_in_bytes) are charged during the try_charge whereas the per-cpu statistics (which back the info in memory.stats) are updated after committing the charge. I assume in the case where charges are not canceled the data in memory.stats and memory.memsw.max_usage_in_bytes - memory.usage_in_bytes should be identical? -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
