Re: Why memory.usage_in_bytes is always increasing after every mmap/dirty/unmap sequence

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

(2012/03/23 18:15), bill4carson wrote:

> 
> 
> On 2012a1'03ae??23ae?JPY 17:04, KAMEZAWA Hiroyuki wrote:
>> (2012/03/23 17:59), bill4carson wrote:
>>
>>>
>>>
>>> On 2012a1'03ae??23ae?JPY 16:19, KAMEZAWA Hiroyuki wrote:
>>>> (2012/03/23 17:04), bill4carson wrote:
>>>>
>>>>> Hi, all
>>>>>
>>>>> I'm playing with memory cgroup, I'm a bit confused why
>>>>> memory.usage in bytes is steadily increasing at 4K page pace
>>>>> after every mmap/dirty/unmap sequence.
>>>>>
>>>>> On linux-3.6.34.10/linux-3.3.0-rc5
>>>>> A simple test case does following:
>>>>>
>>>>> a) mmap 128k memory in private anonymous way
>>>>> b) dirty all 128k to demand physical page
>>>>> c) print memory.usage_in_bytes<-- increased at 4K after every loop
>>>>> d) unmap previous 128 memory
>>>>> e) goto a) to repeat
>>>>
>>>> In Documentation/cgroup/memory.txt
>>>> ==
>>>> 5.5 usage_in_bytes
>>>>
>>>> For efficiency, as other kernel components, memory cgroup uses some optimization
>>>> to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
>>>> method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
>>>> value for efficient access. (Of course, when necessary, it's synchronized.)
>>>> If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
>>>> value in memory.stat(see 5.2).
>>>> ==
>>>>
>>>> In current implementation, memcg tries to charge resource in size of 32 pages.
>>>> So, if you get 32 pages and free 32pages, usage_in_bytes may not change.
>>>> This is affected by caches in other cpus and other flushing operations caused
>>>> by some workload in other cgroups. memcg's usage_in_bytes is not precise in
>>>> 128k degree.
>>>>
>>> Yes, I tried to mmap/dirty/unmap in 32 times, when the usage_in_bytes
>>> reached 128k, it rolls back to 4k again. So it doesn't hurt any more.
>>
>>
>> rolls back before unmap() ?
>>
> After unmap
> 

>>>
>>> I haven't found the code regarding to this behavior.
>>
>>
>> Could you post your test program ?
>>
> Yes, it's a bit of messy, you can mock at me:)


Thank you. I tried.

I checked /proc/<pid>/smaps and compares it before I press 'm' and after I press 'm'.
So, anonymous should be increased 128k.

Then...
==
[root@bluextal kamezawa]# diff -Nru before.txt after.txt | grep Anonymous
 Anonymous:             0 kB
-Anonymous:            12 kB
+Anonymous:           140 kB   <============= 128kbytes you allocated
-Anonymous:             8 kB
+Anonymous:            12 kB   <============= maybe some library's heap.

==

Then, 4k remains even if you free all allocated area by your program, I think.

Thanks,
-Kame









--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>