On Fri, Mar 11, 2011 at 01:09:38PM -0800, Simon Kirby wrote: > On Thu, Mar 10, 2011 at 11:58:56AM +0000, Al Viro wrote: > > > commit d891eedbc3b1b0fade8a9ce60cc0eba1cccb59e5 > > Author: J. Bruce Fields <bfields@xxxxxxxxxxxx> > > Date: Tue Jan 18 15:45:09 2011 -0500 > > > > fs/dcache: allow d_obtain_alias() to return unhashed dentries > > Hmm, I was hoping this or something recently would fix nfs_inode_cache > growing forever and flush processes taking lots of system time since > 2.6.36. For example: > > OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME > 3457486 3454365 99% 0.95K 105601 33 3379232K nfs_inode_cache > 469638 248761 52% 0.10K 12042 39 48168K buffer_head > 243712 216348 88% 0.02K 952 256 3808K kmalloc-16 > 232785 202185 86% 0.19K 11085 21 44340K dentry > 149696 54633 36% 0.06K 2339 64 9356K kmalloc-64 > 115976 106806 92% 0.55K 4142 28 66272K radix_tree_node > 76064 45680 60% 0.12K 2377 32 9508K kmalloc-128 > 62336 53427 85% 0.03K 487 128 1948K kmalloc-32 > 41958 41250 98% 0.75K 1998 21 31968K ext3_inode_cache > > This clears them all, similar to what you posted: > > echo 2 > /proc/sys/vm/drop_caches > sync > echo 2 > /proc/sys/vm/drop_caches > > ...but 2.6.38-rc8 still doesn't seem to fix it. > > http://0x.ca/sim/ref/2.6.37/cpu3_nfs.png > http://www.spinics.net/lists/linux-nfs/msg18212.html > > Any ideas? This started with 2.6.36. Do you have NFSv4 clients that are doing locking? Then it's probably 0997b17360 and 529d7b2a7f on the for-2.6.39 branch at: git://linux-nfs.org/~bfields/linux.git for-2.6.39 Let me know if not. Those should go into 2.6.39 and stable when the merge window opens. I would have tried to slip them into 2.6.38 but they just didn't seem quite trivial enough given where we are in the release process. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
