On Wed, May 21, 2014 at 6:23 AM, Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx> wrote: > Hi Konstantin, > > This patch is already in upstream, but I have another idea of implementing > the similar feature. So let me review this now, and I'll post patches to > complement this patch. > > On Wed, Feb 26, 2014 at 11:57:23AM +0400, Konstantin Khlebnikov wrote: >> After this patch 'page-types' can walk on filesystem mappings and analize >> populated page cache pages mostly without disturbing its state. >> >> It maps chunk of file, marks VMA as MADV_RANDOM to turn off readahead, >> pokes VMA via mincore() to determine cached pages, triggers page-fault >> only for them, and finally gathers information via pagemap/kpageflags. >> Before unmap it marks VMA as MADV_SEQUENTIAL for ignoring reference bits. > > I think that with this patch page-types *does* disturb page cache (not only > of the target file) because it newly populates the pages not faulted in > when page-types starts, which rotates LRU list and adds memory pressure. > To minimize the measurement-disturbance, we need some help in the kernel side. Yes, it racy and sometimes changes state of page-cache, I know that. Dcache state also under fire. [ Also it sometimes races with truncate and dies after SIGBUS, I already have patch for this ] But, I don't see reason why anyone needs this so badly to require this massive change in the kernel. Also I don't quite like interface which you are proposend. I think ioctl would be better, like FIEMAP/BMAP but for pages. Hint: If you're inventing new interface at least make it non-racy and usable for more than one user at once. =) My code has one huge advantage -- it don't need any changes in the kernel and works for old kernels. If you're planning to change here something you should at least keep old code for backward compatibility. I've got another Idea. This mught be done in opposite direction: we could add interface which tells mapping and offset for each page. Finding all pages of particular mapping isn't big deal. What do you think? > >> >> usage: page-types -f <path> >> >> If <path> is directory it will analyse all files in all subdirectories. > > I think -f was reserved for "Walk file address space", so doing file tree > walk looks to me overkill. You can add "directory mode (-d) for this purpose, > although it seems to me that we can/should do this (for example) by combining > with find command. I can show you the example in my patch later. It walks file address space, what's the problem? Removing recursive walk saves couple lines but either kills constuction of overall statistics our might hit the limit of argv size. > >> Symlinks are not followed as well as mount points. Hardlinks aren't handled, >> they'll be dumbed as many times as they are found. Recursive walk brings all >> dentries into dcache and populates page cache of block-devices aka 'Buffers'. I hope you have seen this two paraphes below. That was hint for future hackers =) >> >> Probably it's worth to add ioctl for dumping file page cache as array of PFNs >> as a replacement for this hackish juggling with mmap/madvise/mincore/pagemap. >> >> Also recursive walk could be replaced with dumping cached inodes via some ioctl >> or debugfs interface followed by openning them via open_by_handle_at, this >> would fix hardlinks handling and unneeded population of dcache and buffers. >> This interface might be used as data source for constructing readahead plans >> and for background optimizations of actively used files. >> >> collateral changes: >> + fix 64-bit LFS: define _FILE_OFFSET_BITS instead of _LARGEFILE64_SOURCE >> + replace lseek + read with single pread > > Good, thanks. > >> + make show_page_range() reusable after flush >> >> >> usage example: >> >> ~/src/linux/tools/vm$ sudo ./page-types -L -f page-types >> foffset offset flags >> page-types Inode: 2229277 Size: 89065 (22 pages) >> Modify: Tue Feb 25 12:00:59 2014 (162 seconds ago) >> Access: Tue Feb 25 12:01:00 2014 (161 seconds ago) > > I don't see why page-types needs to show these information. > We have many other tools to check file info, so this small program should > focus on page related things. This tools helps to take snapshot of cached data and analyze why they are here. Pages appears in cache when someone reads files and becomes dirty when someone writes to them. This all about history and time, so when you inversigate what data is still in cache or still dirty you need to know how long they are here. This isn't precisely right, but reasonable enough and don't need any change in the kernel. > > Thanks, > Naoya Horiguchi > >> 0 3cbf3b __RU_lA____M________________________ >> 1 38946a __RU_lA____M________________________ >> 2 1a3cec __RU_lA____M________________________ >> 3 1a8321 __RU_lA____M________________________ >> 4 3af7cc __RU_lA____M________________________ >> 5 1ed532 __RU_lA_____________________________ >> 6 2e436a __RU_lA_____________________________ >> 7 29a35e ___U_lA_____________________________ >> 8 2de86e ___U_lA_____________________________ >> 9 3bdfb4 ___U_lA_____________________________ >> 10 3cd8a3 ___U_lA_____________________________ >> 11 2afa50 ___U_lA_____________________________ >> 12 2534c2 ___U_lA_____________________________ >> 13 1b7a40 ___U_lA_____________________________ >> 14 17b0be ___U_lA_____________________________ >> 15 392b0c ___U_lA_____________________________ >> 16 3ba46a __RU_lA_____________________________ >> 17 397dc8 ___U_lA_____________________________ >> 18 1f2a36 ___U_lA_____________________________ >> 19 21fd30 __RU_lA_____________________________ >> 20 2c35ba __RU_l______________________________ >> 21 20f181 __RU_l______________________________ >> >> >> flags page-count MB symbolic-flags long-symbolic-flags >> 0x000000000000002c 2 0 __RU_l______________________________ referenced,uptodate,lru >> 0x0000000000000068 11 0 ___U_lA_____________________________ uptodate,lru,active >> 0x000000000000006c 4 0 __RU_lA_____________________________ referenced,uptodate,lru,active >> 0x000000000000086c 5 0 __RU_lA____M________________________ referenced,uptodate,lru,active,mmap >> total 22 0 >> >> >> >> ~/src/linux/tools/vm$ sudo ./page-types -f / >> flags page-count MB symbolic-flags long-symbolic-flags >> 0x0000000000000028 21761 85 ___U_l______________________________ uptodate,lru >> 0x000000000000002c 127279 497 __RU_l______________________________ referenced,uptodate,lru >> 0x0000000000000068 74160 289 ___U_lA_____________________________ uptodate,lru,active >> 0x000000000000006c 84469 329 __RU_lA_____________________________ referenced,uptodate,lru,active >> 0x000000000000007c 1 0 __RUDlA_____________________________ referenced,uptodate,dirty,lru,active >> 0x0000000000000228 370 1 ___U_l___I__________________________ uptodate,lru,reclaim >> 0x0000000000000828 49 0 ___U_l_____M________________________ uptodate,lru,mmap >> 0x000000000000082c 126 0 __RU_l_____M________________________ referenced,uptodate,lru,mmap >> 0x0000000000000868 137 0 ___U_lA____M________________________ uptodate,lru,active,mmap >> 0x000000000000086c 12890 50 __RU_lA____M________________________ referenced,uptodate,lru,active,mmap >> total 321242 1254 >> >> Signed-off-by: Konstantin Khlebnikov <koct9i@xxxxxxxxx> >> --- >> tools/vm/page-types.c | 170 ++++++++++++++++++++++++++++++++++++++++++++----- >> 1 file changed, 152 insertions(+), 18 deletions(-) > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@xxxxxxxxx. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a> -- 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
