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@xxxxxxxx
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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>