Re: Access rules for current->memcg

[Nikolay Borisov <n.borisov-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>]

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?