On wed, 23 Mar 2011 09:57:56 +0800, Miao Xie wrote: > On Mon, 21 Mar 2011 08:08:17 -0400, Chris Mason wrote: >>>> I also think that code is racing with the code that frees delayed nodes, >>>> but haven't yet triggered my debugging printks to prove either one. >>> >>> We free delayed nodes when we want to destroy the inode, at that time, just >>> one task, >>> which is destroying inode, can access the delayed nodes, so I think >>> ACCESS_ONCE() is >>> enough. What do you think about? >> >> Great, I see what you mean. The bigger problem right now is that we may do >> a lot of operations in destroy_inode(), which can block the slab >> shrinkers on our metadata operations. That same stress.sh -n 50 run is >> running into OOM. >> >> So we need to rework the part where the final free is done. We could >> keep a ref on the inode until the delayed items are complete, or we >> could let the inode go and make a way to lookup the delayed node when >> the inode is read. > > I find the slab shrinkers just reclaim inodes which are in the inode_unused > list, so if we free delayed nodes before moving the inode into the > inode_unused > list, we can avoid blocking the slab shrinker. Thus maybe we can fix the above > problem by moving btrfs_remove_delayed_node() from btrfs_destroy_inode() > to btrfs_drop_inode(). How do you think about?
This method is not good, because we may do delayed insertion/deletion and free the delayed node when we release the inode, but we may access its delayed node soon. After reading the lockdep message reported by Kitayama, I guess the reason of the slab shrinker block may not be that we do a lot of operations in destroy_inode(), maybe the real reason is that we pass GFP_KERNEL into kzalloc()(in cache_block_group()), which makes the slab shrinkers hang up. (I don't trigger OOM by running stress.sh till now, so I can't locate this bug.) Thanks Miao > >> >> I'll read more today. >> >> -chris >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
