What does the Linux /proc/meminfo "Mapped" topic mean?

Question

What does the Linux /proc/meminfo "Mapped" topic mean? I have seen several one-liners that tell me it is the "Total size of memory in kilobytes that is mapped by devices or libraries with mmap." But I have now spent almost twenty hours searching the 2.6.30.5 kernel source code trying to confirm this statement, and I have been unable to do so -- indeed I see some things which seem to conflict with it.

The "Mapped" count is held in global_page_state[NR_FILE_MAPPED]. The comment near the declaration of NR_FILE_MAPPED says: "Pagecache pages mapped into pagetables. Only modified from process context."

1. Aren't all of the pages referred to by meminfo's "Cached" topic file-backed? Doesn't that mean that all these pages must be "Mapped"? I've looked at a few dozen meminfo listings, from several different architectures, and always the "Mapped" value is much smaller than the "Cached" value.

2. At any given time most of memory is filled with executable images and shared libraries. Looking at /proc/pid/smaps, I see that all of these are mapped into VMAs. Are all of these mapped into memory using mmap()? If so, why is "Mapped" so small? If they aren't mapped into memory using mmap(), how do they get mapped? Calls on handle_mm_fault, which is called by get_user_pages and various architecture-dependent page-fault handlers, increment the "Mapped" count, and they seem to do so for any page associated with a VMA.

3. I've looked at the mmap() functions of a bunch of drivers. Many of these call vm_insert_page or remap_vmalloc_range to establish their mappings, and these functions do increment the "Mapping" count. But a good many other drivers seem to call remap_pfn_range, which, as far as I can tell, doesn't increment the "Mapping" count.

Answer 1

I think the intention is that it counts the number of pages that are mapped from files. In my copy of the source (2.6.31), it is incremented in page_add_file_rmap, and decremented in page_remove_rmap if the page to be removed is not anonymously mapped. page_add_file_rmap is, for example, invoked in __do_fault, again in case the mapping is not anonymous.

So it looks all consistent to me...

Answer 2

1. It's the other way around. Everything in Mapped is also in Cached - Mapped is pagecache data that's been mapped into process virtual memory space. Most pages in Cached are not mapped by processes.

2. The same page can be mapped into many different pagetables - it'll only count in Mapped once, though. So if you have 100 processes running, each with 2MB mapped from /lib/i686/cmov/libc-2.7.so, that'll still only add 2MB to Mapped.