[PATCH] If the machine is full of unmapped clean pagecache pages the kernel won't even try to reclaim inodes

ChangeSet 1.1521.4.18, 2004/12/17 22:17:50-02:00, [email protected]

	[PATCH] If the machine is full of unmapped clean pagecache pages the kernel won't even try to reclaim inodes
	
	> vm_vfs_scan_ratio:
	> ------------------
	> is what proportion of the VFS queues we will scan in one go.
	> A value of 6 for vm_vfs_scan_ratio implies that 1/6th of the
	> unused-inode, dentry and dquot caches will be freed during a
	> normal aging round.
	> Big fileservers (NFS, SMB etc.) probably want to set this
	> value to 3 or 2.
	>
	> The default value is 6.
	> =============================================================
	
	Thanks for the info - but doesn't increasing the value of
	vm_vfs_scan_ratio mean that less of the caches will be freed?
	
	Doing a few tests (on another test file system with 2 million or so
	files and 1Gb of memory) running 'find $disk -type f', with
	vm_vfs_scan_ratio set to 6 (or 10), the first two column values for
	xfs_inode, linvfs_icache and dentry_cache in /proc/slabinfo reach about
	900000 and stay around that value, but setting vm_vfs_scan_ratio to 1,
	then each value still reaches 900000, but then falls to a few thousand
	and increases up to 900000 and then drop away again and repeats.
	
	This still happens when I cat many large files (100Mb) to /dev/null at
	the same time as running the find i.e. the inode caches can still reach
	90% of the memory before being reclaimed (with vm_vfs_scan_ratio set to 1).
	
	If I stop the find process when the inode caches reach about 90% of the
	memory, and then start cat'ing the large files, it appears the inode
	caches are never reclaimed (or longer than it takes to cat 100Gb of data
	to /dev/null) - is this expected behaviour?
	
	It seems the inode cache has priority over cached file data.
	
	What triggers the 'normal ageing round'? Is it possible to trigger this
	earlier (at a lower memory usage), or give a higher priority to cached data?
	
	From: Andrew Morton <[email protected]>
	It does.  If the machine is full of unmapped clean pagecache pages the
	kernel won't even try to reclaim inodes.  This should help a bit:



 vmscan.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff -Nru a/mm/vmscan.c b/mm/vmscan.c
--- a/mm/vmscan.c	2005-01-31 05:20:50 -08:00
+++ b/mm/vmscan.c	2005-01-31 05:20:50 -08:00
@@ -659,13 +659,13 @@
 
 		do {
 			nr_pages = shrink_caches(classzone, gfp_mask, nr_pages, &failed_swapout);
-			if (nr_pages <= 0)
-				return 1;
 			shrink_dcache_memory(vm_vfs_scan_ratio, gfp_mask);
 			shrink_icache_memory(vm_vfs_scan_ratio, gfp_mask);
 #ifdef CONFIG_QUOTA
 			shrink_dqcache_memory(vm_vfs_scan_ratio, gfp_mask);
 #endif
+			if (nr_pages <= 0)
+				return 1;
 			if (!failed_swapout)
 				failed_swapout = !swap_out(classzone);
 		} while (--tries);