On thu, 16 May 2013 22:57:07 +0800, Liu Bo wrote: > On Thu, May 16, 2013 at 10:34:55AM -0400, Chris Mason wrote: >> Quoting Liu Bo (2013-05-16 10:31:39) >>> On Thu, May 16, 2013 at 07:54:17AM -0400, Chris Mason wrote: >>>> Quoting Miao Xie (2013-05-16 03:22:37) >>>>>> I must say that the patch itself looks harmless, the reason is not good enough. >>>>> >>>>> I don't agree with you. >>>>> It is perishing that The memory reclaim task is blocked for a long time. We should avoid >>>>> this problem. >>>> >>>> synchronize_rcu and friends can take a very very long time. I like this >>>> patch as a way to avoid them, it's just keeps the whole kernel moving. >>>> >>>> -chris >>> >>> Okay, that teaches me another lesson, thanks Miao :) >> >> Actually using the rcu api isn't a huge impact. It's just the >> synchronize_rcu variants that should be avoided ;) >> >> -chris >> > > Now that it's so slow, I wonder why not use call_srcu() instead? I have considered this approach, but there is a problem that someone may insert a new inode after we call call_srcu(). So I had to make this patch as a interim solution. My next work is to remove synchronize_srcu() from tree_del_inode(). Thanks Miao -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
