Re: [PATCH] proc/smaps: add proportional size of anonymous page

[Xiaokang <xiaokang.qin@intel.com>]

On 11/11/2014 01:03 AM, Dave Hansen wrote:
> On 11/10/2014 12:48 AM, Qin, Xiaokang wrote:
>> For some case especially under Android, anonymous page sharing is common, for example:
>> 70323000-70e41000 rw-p 00000000 fd:00 120004                             /data/dalvik-cache/x86/system@framework@boot.art
>> Size:              11384 kB
>> Rss:                8840 kB
>> Pss:                 927 kB
>> Shared_Clean:       5720 kB
>> Shared_Dirty:       2492 kB
>> Private_Clean:        16 kB
>> Private_Dirty:       612 kB
>> Referenced:         7896 kB
>> Anonymous:          3104 kB
>> PropAnonymous:       697 kB
>
> Please don't top post.
>
>> The only Anonymous here is confusing to me. What I really want to
>> know is how many anonymous page is there in Pss. After exposing
>> PropAnonymous, we could know 697/927 is anonymous in Pss.
>> I suppose the Pss - PropAnonymous = Proportional Page cache size for
>> file based memory and we want to break down the page cache into
>> process level, how much page cache each process consumes.
>
> Ahh, so you're talking about the anonymous pages that result from
> copy-on-write copies of private file mappings?  That wasn't very clear
> from the description at all.

Yes, sorry for the unclear description.

>
> I'll agree that this definitely provides a bit of data that we didn't
> have before, albeit a fairly obscure one.
>
> But, what's the goal of this patch?  Why are you doing this?  Was there
> some application whose behavior you were not able to explain before, but
> can after this patch?

Under Android, when user switches the application the previous 
application will not exit but switch to background so that next time 
this application could be resumed to foreground very quickly.
So there may be many applications running at background and Android 
introduces lowmemory killer to kill processes to free memory according 
to oom_adj when memory is short. Some processes with high value of 
oom_adj will be killed first like the background running non-critical 
application. The memory used by these processes could be treated as 
"free" because it could be freed by killing. Hence under Android the 
"free" RAM is composed of: 1) memory using by non-critical application 
that could be killed easily, 2) page cache, 3) physical free page. We 
are using sum of Pss in smaps to measure the process consumed memory for 
1) and get the info for 2) 3) from /proc/meminfo. Then we have the 
problem that file based memory will be double accounted in 1) and 2). To 
mitigate the double accounting issue here, we need to know the double 
accounting part - proportional page cache size, and do the deduction.

If the goal is providing a "Proportional Page
> cache size", why do that in an indirect way?  Have you explored doing
> the same measurement with /proc/$pid/pagemap?  Is it possible with that
> interface?
>
I checked the flags in /proc/kpageflags but have no idea about what 
flags should be used to identify the pagecache. It will be appreciated 
if you could provide some advice.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>