Re: Reducing inode cache usage on 2.4?
From: Marcelo Tosatti
Date: Mon Dec 20 2004 - 12:26:49 EST
On Mon, Dec 20, 2004 at 04:10:45PM +0100, Andrea Arcangeli wrote:
> On Mon, Dec 20, 2004 at 10:46:04AM -0200, Marcelo Tosatti wrote:
> > 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?
> I wouldn't touch the defaults, but the sysctl is there so if you've a
> strange workload you can tune for it.
> There's nothing wrong with dcache/icache growing a lot.
The thing is right now we dont try to reclaim from icache/dcache _at all_
if enough clean pagecache pages are found and reclaimed.
Its sounds unfair to me.
> A cat of a large file is polluting the cache, so that's not a workload that should shrink
> the dcache/icache.
Why not? If we have a lot of them they will probably be hurting performace, which seems
to be the case now.
> I'd prefer a feedback based on a real useful workload
> before even considering touching the defaults at this time.
Following this logic any workload which generates pagecache and happen to, most times,
have enough pagecache clean to be reclaimed should not reclaim the i/dcache's.
Which is not right.
But yes, feedback based on other workloads is required. I'm hoping people do test
the next 2.4.29-pre3 and send feedback.
So I'll probably revert the patch if any considerable regression is found.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/