Look and enjoy. If prune_icache() doesn't shoot its goal, it
tries to sync some dirty inodes and look for freeable ones one more
time. The sad thing being, counter is not reset on the second pass.
I.e. you end up with nr_unused decremented by 2 * freed_at_the_first_pass +
Result: underestimated nr_unused. Since that's what we use for
determining the pressure on icache...
Seeing negative number in /proc/sys/fs/inode-nr is... well, an
Please, apply the patch below.
PS: _Ouch_. 6 hours of hunting for this one.
diff -urN S4/fs/inode.c S4-prune_icache/fs/inode.c
--- S4/fs/inode.c Sat Apr 28 02:12:56 2001
+++ S4-prune_icache/fs/inode.c Sat Apr 28 21:37:25 2001
@@ -612,12 +612,13 @@
struct list_head *entry, *freeable = &list;
- int count = 0, synced = 0;
+ int count, synced = 0;
struct inode * inode;
+ count = 0;
entry = inode_unused.prev;
while (entry != &inode_unused)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:21 EST