Messages in this thread |  | | | Date | Wed, 9 May 2012 06:59:14 -0700 | | From | "Paul E. McKenney" <> | | Subject | Re: [PATCH] vfs: Speed up deactivate_super for non-modular filesystems |
| |
On Wed, May 09, 2012 at 05:55:57PM +1000, Nick Piggin wrote: > On 8 May 2012 11:07, Eric W. Biederman <ebiederm@xmission.com> wrote: > > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
[ . . . ]
> >> Is there anything in there for which synchronous operation is required? > >> If not, one approach would be to drop the rcu_barrier() calls to a > >> workqueue or something similar. > > > > We need to drain all of the rcu callbacks before we free the slab > > and unload the module. > > > > This actually makes deactivate_locked_super the totally wrong place > > for the rcu_barrier. We want the rcu_barrier in the module exit > > routine where we destroy the inode cache. > > > > What I see as the real need is the filesystem modules need to do: > > rcu_barrier() > > kmem_cache_destroy(cache); > > > > Perhaps we can add some helpers to make it easy. But I think > > I would be happy today with simply moving the rcu_barrier into > > every filesystems module exit path, just before the file system > > module destoryed it's inode cache. > > No, because that's not the only requirement for the rcu_barrier. > > Making it asynchronous is not something I wanted to do, because > then we potentially have a process exiting from kernel space after > releasing last reference on a mount, but the mount does not go > away until "some time" later. Which is crazy.
In any case, I am looking into making concurrent calls to rcu_barrier() share each others' work, so if asynchronous turns out to be needed, it will be efficient.
Thanx, Paul
> However. We are holding vfsmount_lock for read at the point > where we ever actually do anything with an "rcu-referenced" > dentry/inode. I wonder if we could use this to get i_sb pinned. >
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |