Re: [PATCH] procfs: expose page cache contents

[Dave Chinner <david@fromorbit.com>]

On Thu, Apr 25, 2013 at 02:27:10PM +0000, Nick White wrote:
> From: Nick White <nwhite@palantir.com>
> 
> This patch adds a /proc/page_cache file to the procfs. The file contains a
> line for each inode belonging to a block filesystem which has one or more
> of its pages in memory (as determined by PageUptodate). This line includes
> a run-length-encoded bitmap of which pages are up-to-date, starting with
> pages that aren't (so a string 0,4,2,3 means the first four pages are
> up-to-date, the next two aren't and the final three are).
> 
> A sample output (columns are inode, super block id, total number of pages
> for this inode, run-length-encoded bitmap of which pages are up-to-date,
> total pages up-to-date, total pages not up-to-date):
> 
> 148073	sda1	1	0,1	1	0
> 397793	sda1	4518	0,3,2,1,67,32,231,1,29,2,396,9,32,1,12,2,2613,1,1084	52	44
> 66
> 133941	sda1	13	0,4,3,3,3	7	6
> 173947	sda1	43	0,5,2,1,1,4,1,1,2,1,8,6,1,10	28	15
> 148499	sda1	4	0,4	4	0
>
> It's currently possible to query this information for a specific file from
> userspace using mmap / mincore system calls, however this patch solves the
> slightly different question "What's in the cache?" (not "Is this in the
> cache?").

Leaving aside the implementation problems in your patch (and there
are lots of them), what use does this information have?

It's out of date by the time the caller can make any sense of it,
and there's nothing the caller can do with the information, anyway.
Indeed, the act of dumping this information and storing/parsing it
in userspace will generate memory pressure and perturb the very
thing you are trying to measure....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com