On Mon, Feb 15, 2016 at 09:57:42PM -0800, Nag Avadhanam wrote:

On Mon, 15 Feb 2016, Dave Chinner wrote:

quoted

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@fromorbit.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>