Re: [PATCH] prune_icache_sb

On Thu, 30 Nov 2006 11:05:32 -0500
Wendy Cheng <wcheng@xxxxxxxxxx> wrote:

How about a simple and plain change with this uploaded patch ....

The idea is, instead of unconditionally dropping every buffer associated
with the particular mount point (that defeats the purpose of page
caching), base kernel exports the "drop_pagecache_sb()" call that allows
page cache to be trimmed. More importantly, it is changed to offer the
choice of not randomly purging any buffer but the ones that seem to be
unused (i_state is NULL and i_count is zero). This will encourage
filesystem(s) to pro actively response to vm memory shortage if they
choose so.

argh.

In Linux a filesystem is a dumb layer which sits between the VFS and the
I/O layer and provides dumb services such as reading/writing inodes,
reading/writing directory entries, mapping pagecache offsets to disk
blocks, etc. (This model is to varying degrees incorrect for every
post-ext2 filesystem, but that's the way it is).

We do not want to go "encouraging" filesystems to play games tuning and
trimming VFS caches and things like that. If a patch doing that were to
turn up it would be heartily shouted at and the originator would be asked
to go off and implement the functionality in core VFS so that a) all
filesystems can immediately utilise it and b) other filesystems aren't
tempted to go off and privately implement something similar.

So please bear this philosophy in mind, and think about this feature from
that perspective.

One approach might be to add a per-superblock upper-bound on the number of
cached dentries and/or inodes. Typically that would be controlled by a
(re)mount option. Although we could perhaps discuss a sysfs representation
of this (and, presumably, other mount options).

But I'd expect such a proposal to have a hard time, because we'd need to
know why such a thing is needed: we prefer auto-tuning, and that's what we
have now, so what's gone wrong with it and how can we fix it, rather than
adding a manual override?

From our end (cluster locks are expensive - that's why we cache them),
one of our kernel daemons will invoke this newly exported call based on
a set of pre-defined tunables. It is then followed by a lock reclaim
logic to trim the locks by checking the page cache associated with the
inode (that this cluster lock is created for). If nothing is attached to
the inode (based on i_mapping->nrpages count), we know it is a good
candidate for trimming and will subsequently drop this lock (instead of
waiting until the end of vfs inode life cycle).

Again, I don't understand why you're tying the lifetime of these locks to
the VFS inode reclaim mechanisms. Seems odd.

If you want to put an upper bound on the number of in-core locks, why not
string them on a list and throw away the old ones when the upper bound is
reached?

Did you look at improving that lock-lookup algorithm, btw? Core kernel has
no problem maintaining millions of cached VFS objects - is there any reason
why your lock lookup cannot be similarly efficient?

Note that I could do invalidate_inode_pages() within our kernel modules
to accomplish what drop_pagecache_sb() does (without coming here to bug
people) but I don't have access to inode_lock as an external kernel
module. So either EXPORT_SYMBOL(inode_lock) or this patch ?

The end result (of this change) should encourage filesystem to actively
avoid depleting too much memory

That is _not_ a filesytem responsibility! inode cache is owned and
maintained by the VFS.

and we'll encourage our applications to
understand clustering locality issues.

?

Haven't tested this out though - would appreciate some comments before
spending more efforts on this direction.

-- Wendy



-
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/

Relevant Pages

  • [PATCH 1/2] VFS: update overview document
    ... -The Virtual File System (otherwise known as the Virtual Filesystem ... The pathname argument is used by the VFS to search through the ... -directory entry cache (dentry cache or "dcache"). ... -An individual dentry usually has a pointer to an inode. ...
    (Linux-Kernel)
  • [RFC][PATCH] VFS: update documentation (take #2)
    ... filesystem interface to userspace programs. ... These are taken from the inode data. ... owner: for internal VFS use: you should initialize this to NULL ... struct super_block *sb: the superblock structure. ...
    (Linux-Kernel)
  • [RFC][PATCH] VFS: update documentation
    ... -This describes the filesystem. ... owner: for internal VFS use: you should initialise this to NULL ... struct super_block *sb: the superblock structure. ... dirty_inode: this method is called by the VFS to mark an inode dirty. ...
    (Linux-Kernel)
  • Re: [PATCH 5/6] vmscan: Write out ranges of pages contiguous to the inode where possible
    ... The inode is pinned and the page lock released before ... submitting the range to the filesystem. ... writearound around the target page. ...
    (Linux-Kernel)
  • Re: [PATCH] prune_icache_sb
    ... It is, however, not ok to give filesystem developerthis very same function to trim their own page cache if the filesystems choose to do so"? ... Linux kernel, particularly the VFS layer, is starting to show signs of inadequacy as the software components built upon it keep growing. ... It is then followed by a lock reclaim logic to trim the locks by checking the page cache associated with the inode. ...
    (Linux-Kernel)