Mapped more than Cached in /proc/meminfo
From: z0032oom@gmail.com (=/_00/\/\)
Date: 2011-08-10 16:42:35
Hi, Please find my reply inlined. On Wed, Aug 10, 2011 at 1:04 PM, Prateek Sharma [off-list ref]wrote:
On Wed, Aug 10, 2011 at 12:56 PM, Mulyadi Santosa < mulyadi.santosa at gmail.com> wrote:quoted
Hi/// On 09/08/2011, =/_00/\/\ [off-list ref] wrote:quoted
Hi, Thanks for replying Here is one observation worth mentioning. On boot system it shows Mapped < Cached (In fact much less)quite predictable.... during booting phase, your system read() much by doesn't mmap() that much....quoted
After using system for some time following commands are executed. # sync and echo 3 > /proc/sys/vm/drop_cache Whenever above command is executed I can see Mapped > Cached.by echoing "3" to drop_cache, you flush the content of page cache as much as possible ...Here is my understanding of what drop_page_cache does: All page-cache pages are 'dropped' except the following: 1. Dirty pages. (they are *not* synced) 2. Mapped pages (pages 'in use' , mapped by rmap ) (There are a few more exceptions i dont recall now.)
But even in this case Cached (/proc/meminfo) should be always greater than
Mapped(/proc/meminfo) (As it will contain mapped + Unmapped pages)
I also saw that Cached (/proc/meminfo) does not include Buffer Cache.
========= fs/proc/meminfo.c ========
cached = global_page_state(NR_FILE_PAGES) -
total_swapcache_pages - i.bufferram;
==============================
Even if drop_cache is not done is it ever possible to get Cached < Mapped ?
Regards,
~/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110810/8d9f2b00/attachment.html