Thanks Steven for trying it out. > I can see it bringing down the number of pages needed to be saved dramatically. Yes, I agree. However, note that wc does not count the size of the page caches correctly since 'get_map_pages' gives you a range. In your example of the less command, actually the total sizes of page_cache_size and get_map_pages look the same. Instead of less, running a large binary such as Chrome (232MB) gives us a better example. '# trace-cmd record -e filemap chrome --version' showed 58% reduction from 42MB to 17MB in my environment. - Total size of mm_filemap_add_to_page_cache: 42,958,848 bytes - With mm_filemap_map_pages and mm_filemap_get_pages: 17,993,728 bytes By the way, 'mm_filemap_map_pages' traces a range requested to populate, which includes pages that are not in caches yet and thus are skipped. So, you need to calculate the intersection with mm_filemap_add_to_page_cache to see page caches that are actually mapped. I'm wondering if we should put a trace event per each successful page mapping event as mm_filemap_add_to_page_cache does, by putting an event inside the page map loop.
