aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/filesystems/vfs.txt
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2011-07-08 00:14:45 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2011-07-20 20:47:41 -0400
commit8ab47664d51a69ea79fe70bb07ca80664f74f76b (patch)
treea0cc73a909840edfb23b4b4490c39fd222cce0fa /Documentation/filesystems/vfs.txt
parent0e1fdafd93980eac62e778798549ce0f6073905c (diff)
vfs: increase shrinker batch size
Now that the per-sb shrinker is responsible for shrinking 2 or more caches, increase the batch size to keep econmies of scale for shrinking each cache. Increase the shrinker batch size to 1024 objects. To allow for a large increase in batch size, add a conditional reschedule to prune_icache_sb() so that we don't hold the LRU spin lock for too long. This mirrors the behaviour of the __shrink_dcache_sb(), and allows us to increase the batch size without needing to worry about problems caused by long lock hold times. To ensure that filesystems using the per-sb shrinker callouts don't cause problems, document that the object freeing method must reschedule appropriately inside loops. Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'Documentation/filesystems/vfs.txt')
-rw-r--r--Documentation/filesystems/vfs.txt6
1 files changed, 6 insertions, 0 deletions
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index fd24f34f120..6bf85b78cfe 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -317,6 +317,12 @@ or bottom half).
317 the VM is trying to reclaim under GFP_NOFS conditions, hence this 317 the VM is trying to reclaim under GFP_NOFS conditions, hence this
318 method does not need to handle that situation itself. 318 method does not need to handle that situation itself.
319 319
320 Implementations must include conditional reschedule calls inside any
321 scanning loop that is done. This allows the VFS to determine
322 appropriate scan batch sizes without having to worry about whether
323 implementations will cause holdoff problems due to large scan batch
324 sizes.
325
320Whoever sets up the inode is responsible for filling in the "i_op" field. This 326Whoever sets up the inode is responsible for filling in the "i_op" field. This
321is a pointer to a "struct inode_operations" which describes the methods that 327is a pointer to a "struct inode_operations" which describes the methods that
322can be performed on individual inodes. 328can be performed on individual inodes.