On Mon, Feb 15, 2016 at 09:57:42PM -0800, Nag Avadhanam wrote: > On Mon, 15 Feb 2016, Dave Chinner wrote: > >So, to pick a random active server here: > > > > before after > >Active(file): 12103200 kB 24060 kB > >Inactive(file): 5976676 kB 1380 kB > >Mapped: 31308 kB 31308 kB > > > >How much was not reclaimed? Roughly the same number of pages as the > >Mapped count, and that's exactly what we'd expect to see from the > >above page walk counting code. Hence a slightly better approximation > >of the pages that dropping caches will reclaim is: > > > >reclaimable pages = active + inactive - dirty - writeback - mapped > > Thanks Dave. I considered that, but see this. > > Mapped page count below is much higher than the (active(file) + > inactive (file)). Yes. it's all unreclaimable from drop caches, though. > Mapped seems to include all page cache pages mapped into the process > memory, including the shared memory pages, file pages and few other > type > mappings. > > I suppose the above can be rewritten as (mapped is still high): > > reclaimable pages = active + inactive + shmem - dirty - writeback - mapped > > What about kernel pages mapped into user address space? Does "Mapped" > include those pages as well? How do we exclude them? What about > device mappings? Are these excluded in the "Mapped" pages > calculation? /me shrugs. I have no idea - I really don't care about what pages are accounted as mapped. I assumed that the patch proposed addressed your requirements and so I suggested an alternative that provided almost exactly the same information but erred on the side of underestimation and hence solves your problem of drop_caches not freeing as much memory as you expected.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
