From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [RFC, PATCH] fs: push rcu_barrier() from deactivate_locked_super() to filesystems Date: Fri, 8 Jun 2012 14:43:58 -0700 Message-ID: References: <1339190930-17233-1-git-send-email-kirill.shutemov@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Latchesar Ionkov , Dave Kleikamp , jfs-discussion@lists.sourceforge.net, Phillip Lougher , Jan Kara , Kai Bankett , logfs@logfs.org, Frederic Weisbecker , Anders Larsen , Trond Myklebust , William Irwin , "Dmitry V. Levin" , David Howells , Dustin Kirkland , Andreas Dilger , Mikulas Patocka , KONISHI Ryusuke , Petr Vandrovec , linux-afs@lists.infradead.org, Alexey Khoroshilov , linux-cifs@vger.kernel.org, Namjae Jeon , linux-nilfs@vger.kernel.org, fuse-devel@lists.source To: "Kirill A. Shutemov" , Pekka Enberg Return-path: In-Reply-To: <1339190930-17233-1-git-send-email-kirill.shutemov@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org@lists.infradead.org List-Id: linux-ext4.vger.kernel.org On Fri, Jun 8, 2012 at 2:28 PM, Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > There's no reason to call rcu_barrier() on every deactivate_locked_super(). > We only need to make sure that all delayed rcu free inodes are flushed > before we destroy related cache. > > Removing rcu_barrier() from deactivate_locked_super() affects some > fas paths. E.g. on my machine exit_group() of a last process in IPC > namespace takes 0.07538s. rcu_barrier() takes 0.05188s of that time. I think we should just delete it. kmem_cache_destroy() (at least for SLUB) already has: if (s->flags & SLAB_DESTROY_BY_RCU) rcu_barrier(); in it. But I think it's too late - it gets called *after* we do kmem_cache_close(), and I get the feeling that we should do it before. Shouldn't that be sufficient? And if other slab allocators don't have this, we should add it to them too. Hmm? Linus ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/