Re: Better pagecache statistics ?

Christoph Lameter
2005-12-01T21:16:56Z

We are actually looking at have better pagecache statistics and I have
been trying out a series of approaches. The direct need right now is to
have some statistics on the size of the pagecache and the number of
unmapped file backed pages per node.

With those numbers one would be able to do a local page eviction if memory
on a node runs low. Per cpu counters exist for some of these but these are
only meaningful if they are summed up (despite drivers/base/node.c
seemingly allowing access to per node information).

One pathological case that we frequently encounter is that an application
does lots of file I/O that saturates a node and then terminates. At that
point a high number of unmapped pagecache pages exist that are not
reclaimed because other nodes still have enough free memory. If a counter
would be available per node then we could check if the numer of unmapped
pagecache pages is high and if that is the case run kswapd on one specific
node.

In my various attempts to get some form of statistics for that purpose I
encountered the problem that I need to modify critical code paths in the
VM.

One solution would be to add an atomic counter to the zone for the
number of mapped and the number pagecache pages. However, this would mean
that these counters have to be incremented and decremented for everypage
removed and added to the pagecache.

Another one would be to have a node based per cpu array that is summed up
in regular intervals to create true per node statistics. However, numbers
are then not current and its not feasable to add them up for every check.