On Thu, Apr 25, 2013 at 02:27:10PM +0000, Nick White wrote: > From: Nick White <nwhite@xxxxxxxxxxxx> > > 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@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
