Messages in this thread | | | Date | Mon, 20 Dec 2004 20:20:46 +0100 | From | Andrea Arcangeli <> | Subject | Re: Reducing inode cache usage on 2.4? |
| |
On Fri, Dec 17, 2004 at 05:21:04PM -0800, Andrew Morton wrote: > James Pearson <james-p@moving-picture.com> wrote: > > > > It seems the inode cache has priority over cached file data. > > 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: > > --- 24/mm/vmscan.c~a 2004-12-17 17:18:31.660254712 -0800 > +++ 24-akpm/mm/vmscan.c 2004-12-17 17:18:41.821709936 -0800 > @@ -659,13 +659,13 @@ int fastcall try_to_free_pages_zone(zone > > 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);
I'm worried this is too aggressive by default and it may hurt stuff. The real bug is that we don't do anything when too many collisions happens in the hashtables. That is the thing to work on. We should free colliding entries in the background after a 'touch' timeout. That should work pretty well to age the dcache proprerly too. But the above will just shrink everything all the time and it's going to break stuff. For 2.6 we can talk about the background shrink based on timeout.
My only suggestion for 2.4 is to try with vm_cache_scan_ratio = 20 or higher (or alternatively vm_mapped_ratio = 50 or = 20). There's a reason why everything is tunable by sysctl.
I don't think the vm_lru_balance_ratio is the one he's interested about. vm_lru_balance_ratio controls how much work is being done at every dcache/icache shrinking.
His real objective is to invoke the dcache/icache shrinking more frequently, how much work is being done at each pass is a secondary issue. If we don't invoke it, nothing will be shrunk, no matter what is the value of vm_lru_balance_ratio.
Hope this helps funding an optimal tuning for the workload. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |