lkml.org 
[lkml]   [2004]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Reducing inode cache usage on 2.4?
On Mon, Dec 20, 2004 at 01:47:46PM +0000, James Pearson wrote:
> I've tested the patch on my test setup - running a 'find $disk -type f'
> and a cat of large files to /dev/null at the same time does indeed
> reduce the size of the inode and dentry caches considerably - the first
> column numbers for fs_inode, linvfs_icache and dentry_cache in
> /proc/slabinfo hover at about 400-600 (over 900000 previously).
> However, is this going a bit to far the other way? When I boot the
> machine with 4Gb RAM, the inode and dentry caches are squeezed to the
> same amounts, but it may be the case that it would be more beneficial to
> have more in the inode and dentry caches? i.e. I guess some sort of
> tunable factor that limits the minimum size of the inode and dentry
> caches in this case?

One can increase vm_vfs_scan_ratio if required, but hopefully this change
will benefit all workloads.

Andrew, Andrea, do you think of any workloads which might be hurt by this change?

> But saying that, I notice my 'find $disk -type f' (with about 2 million
> files) runs a lot faster with the smaller inode/dentry caches - about 1
> or 2 minutes with the patched kernel compared with about 5 to 7 minutes
> with the unpatched kernel - I guess it was taking longer to search the
> inode/dentry cache than reading direct from disk.

Wonderful.

>
> James Pearson
>
> Marcelo Tosatti wrote:
> >James,
> >
> >Can apply Andrew's patch and examine the results?
> >
> >I've merged it to mainline because it looks sensible.
> >
> >Thanks Andrew!
> >
> >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);
> >>_
> >>
> >>
> >>
> >>>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?
> >>
> >>You could also try lowering /proc/sys/vm/vm_mapped_ratio. That will cause
> >>inodes to be reaped more easily, but will also cause more swapout.
> >
> >
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.085 / U:0.060 seconds]
©2003-2011 Jasper Spaans