From: Andrew Morton <akpm@linux-foundation.org>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Boaz Harrosh <bharrosh@panasas.com>, Tao Ma <boyu.mt@taobao.com>,
Nick Piggin <npiggin@kernel.dk>,
"Dmitry V. Levin" <ldv@altlinux.org>,
v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org,
ceph-devel@vger.kernel.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org,
codalist@TELEMANN.coda.cs.cmu.edu, ecryptfs@vger.kernel.org,
osd-dev@open-osd.org, linux-ext4@vger.kernel.org,
fuse-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org,
jfs-discussion@lists.sourceforge.net, logfs@logfs.org,
linux-nfs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, ocfs2-devel@oss.oracle.com,
reiserfs-devel@vger.kernel.org
Subject: Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems
Date: Fri, 8 Jun 2012 15:25:50 -0700 [thread overview]
Message-ID: <20120608152550.258d6a30.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120608221446.GA18250@otc-wbsnb-06>
On Sat, 9 Jun 2012 01:14:46 +0300
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:
> On Fri, Jun 08, 2012 at 03:02:53PM -0700, Andrew Morton wrote:
> > On Sat, 9 Jun 2012 00:41:03 +0300
> > "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:
> >
> > > 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.
> >
> > What an unpleasant patch. Is final-process-exiting-ipc-namespace a
> > sufficiently high-frequency operation to justify the change?
This, please.
> > I don't really understand what's going on here. Are you saying that
> > there is some filesystem against which we run deactivate_locked_super()
> > during exit_group(), and that this filesystem doesn't use rcu-freeing
> > of inodes? The description needs this level of detail, please.
You still haven't explained where this deactivate_locked_super() call
is coming from. Oh well.
> I think the rcu_barrier() is in wrong place. We need it to safely destroy
> inode cache. deactivate_locked_super() is part of umount() path, but all
> filesystems I've checked have inode cache for whole filesystem, not
> per-mount.
Well from a design perspective, putting the rcu_barrier() in the vfs is
the *correct* place. Individual filesystems shouldn't be hard-coding
knowledge about vfs internal machinery.
A neater implementation might be to add a kmem_cache* argument to
unregister_filesystem(). If that is non-NULL, unregister_filesystem()
does the rcu_barrier() and destroys the cache. That way we get to
delete (rather than add) a bunch of code from all filesystems and new
and out-of-tree filesystems cannot forget to perform the rcu_barrier().
> > The implementation would be less unpleasant if we could do the
> > rcu_barrier() in kmem_cache_destroy(). I can't see a way of doing that
> > without adding a dedicated slab flag, which would require editing all
> > the filesystems anyway.
>
> I think rcu_barrier() for all kmem_cache_destroy() would be too expensive.
That is not what I proposed.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: jfs-discussion@lists.sourceforge.net,
"Dmitry V. Levin" <ldv@altlinux.org>,
linux-mtd@lists.infradead.org, linux-afs@lists.infradead.org,
codalist@TELEMANN.coda.cs.cmu.edu, linux-cifs@vger.kernel.org,
linux-nilfs@vger.kernel.org, Boaz Harrosh <bharrosh@panasas.com>,
v9fs-developer@lists.sourceforge.net, linux-ext4@vger.kernel.org,
Nick Piggin <npiggin@kernel.dk>,
fuse-devel@lists.sourceforge.net, Tao Ma <boyu.mt@taobao.com>,
ecryptfs@vger.kernel.org, reiserfs-devel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net,
samba-technical@lists.samba.org, linux-kernel@vger.kernel.org,
logfs@logfs.org, ocfs2-devel@oss.oracle.com,
linux-fsdevel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-btrfs@vger.kernel.org, osd-dev@open-osd.org
Subject: Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems
Date: Fri, 8 Jun 2012 15:25:50 -0700 [thread overview]
Message-ID: <20120608152550.258d6a30.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120608221446.GA18250@otc-wbsnb-06>
On Sat, 9 Jun 2012 01:14:46 +0300
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:
> On Fri, Jun 08, 2012 at 03:02:53PM -0700, Andrew Morton wrote:
> > On Sat, 9 Jun 2012 00:41:03 +0300
> > "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:
> >
> > > 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.
> >
> > What an unpleasant patch. Is final-process-exiting-ipc-namespace a
> > sufficiently high-frequency operation to justify the change?
This, please.
> > I don't really understand what's going on here. Are you saying that
> > there is some filesystem against which we run deactivate_locked_super()
> > during exit_group(), and that this filesystem doesn't use rcu-freeing
> > of inodes? The description needs this level of detail, please.
You still haven't explained where this deactivate_locked_super() call
is coming from. Oh well.
> I think the rcu_barrier() is in wrong place. We need it to safely destroy
> inode cache. deactivate_locked_super() is part of umount() path, but all
> filesystems I've checked have inode cache for whole filesystem, not
> per-mount.
Well from a design perspective, putting the rcu_barrier() in the vfs is
the *correct* place. Individual filesystems shouldn't be hard-coding
knowledge about vfs internal machinery.
A neater implementation might be to add a kmem_cache* argument to
unregister_filesystem(). If that is non-NULL, unregister_filesystem()
does the rcu_barrier() and destroys the cache. That way we get to
delete (rather than add) a bunch of code from all filesystems and new
and out-of-tree filesystems cannot forget to perform the rcu_barrier().
> > The implementation would be less unpleasant if we could do the
> > rcu_barrier() in kmem_cache_destroy(). I can't see a way of doing that
> > without adding a dedicated slab flag, which would require editing all
> > the filesystems anyway.
>
> I think rcu_barrier() for all kmem_cache_destroy() would be too expensive.
That is not what I proposed.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Boaz Harrosh <bharrosh@panasas.com>, Tao Ma <boyu.mt@taobao.com>,
Nick Piggin <npiggin@kernel.dk>,
"Dmitry V. Levin" <ldv@altlinux.org>,
v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org,
ceph-devel@vger.kernel.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org,
codalist@TELEMANN.coda.cs.cmu.edu, ecryptfs@vger.kernel.org,
osd-dev@open-osd.org, linux-ext4@vger.kernel.org,
fuse-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org,
jfs-discussion@lists.sourceforge.net, logfs@logfs.org,
linux-nfs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, ocfs2-devel@oss.oracle.com,
reiserfs-devel@vger.kernel.org
Subject: [Ocfs2-devel] [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems
Date: Fri, 8 Jun 2012 15:25:50 -0700 [thread overview]
Message-ID: <20120608152550.258d6a30.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120608221446.GA18250@otc-wbsnb-06>
On Sat, 9 Jun 2012 01:14:46 +0300
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:
> On Fri, Jun 08, 2012 at 03:02:53PM -0700, Andrew Morton wrote:
> > On Sat, 9 Jun 2012 00:41:03 +0300
> > "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:
> >
> > > 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.
> >
> > What an unpleasant patch. Is final-process-exiting-ipc-namespace a
> > sufficiently high-frequency operation to justify the change?
This, please.
> > I don't really understand what's going on here. Are you saying that
> > there is some filesystem against which we run deactivate_locked_super()
> > during exit_group(), and that this filesystem doesn't use rcu-freeing
> > of inodes? The description needs this level of detail, please.
You still haven't explained where this deactivate_locked_super() call
is coming from. Oh well.
> I think the rcu_barrier() is in wrong place. We need it to safely destroy
> inode cache. deactivate_locked_super() is part of umount() path, but all
> filesystems I've checked have inode cache for whole filesystem, not
> per-mount.
Well from a design perspective, putting the rcu_barrier() in the vfs is
the *correct* place. Individual filesystems shouldn't be hard-coding
knowledge about vfs internal machinery.
A neater implementation might be to add a kmem_cache* argument to
unregister_filesystem(). If that is non-NULL, unregister_filesystem()
does the rcu_barrier() and destroys the cache. That way we get to
delete (rather than add) a bunch of code from all filesystems and new
and out-of-tree filesystems cannot forget to perform the rcu_barrier().
> > The implementation would be less unpleasant if we could do the
> > rcu_barrier() in kmem_cache_destroy(). I can't see a way of doing that
> > without adding a dedicated slab flag, which would require editing all
> > the filesystems anyway.
>
> I think rcu_barrier() for all kmem_cache_destroy() would be too expensive.
That is not what I proposed.
next prev parent reply other threads:[~2012-06-08 22:25 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-08 21:41 [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems Kirill A. Shutemov
2012-06-08 21:41 ` Kirill A. Shutemov
2012-06-08 21:41 ` Kirill A. Shutemov
2012-06-08 22:00 ` [RFC, PATCH] " Kirill A. Shutemov
2012-06-08 22:00 ` Kirill A. Shutemov
2012-06-08 22:00 ` Kirill A. Shutemov
2012-06-08 22:06 ` Linus Torvalds
2012-06-08 22:06 ` [Ocfs2-devel] " Linus Torvalds
2012-06-08 22:06 ` Linus Torvalds
2012-06-08 22:06 ` Linus Torvalds
2012-06-08 22:25 ` Al Viro
2012-06-08 22:25 ` [Ocfs2-devel] " Al Viro
2012-06-08 22:25 ` Al Viro
2012-06-08 22:25 ` Al Viro
2012-06-08 22:02 ` [RFC, PATCH, RESEND] " Andrew Morton
2012-06-08 22:02 ` [Ocfs2-devel] " Andrew Morton
2012-06-08 22:02 ` Andrew Morton
2012-06-08 22:14 ` Kirill A. Shutemov
2012-06-08 22:14 ` Kirill A. Shutemov
2012-06-08 22:23 ` Al Viro
2012-06-08 22:23 ` [Ocfs2-devel] " Al Viro
2012-06-08 22:23 ` Al Viro
2012-06-08 22:27 ` Linus Torvalds
2012-06-08 22:27 ` [Ocfs2-devel] " Linus Torvalds
2012-06-08 22:27 ` Linus Torvalds
2012-06-08 22:25 ` Andrew Morton [this message]
2012-06-08 22:25 ` [Ocfs2-devel] " Andrew Morton
2012-06-08 22:25 ` Andrew Morton
2012-06-08 22:27 ` Al Viro
2012-06-08 22:27 ` [Ocfs2-devel] " Al Viro
2012-06-08 22:27 ` Al Viro
2012-06-08 22:31 ` Andrew Morton
2012-06-08 22:31 ` [Ocfs2-devel] " Andrew Morton
2012-06-08 22:31 ` Andrew Morton
2012-06-08 22:36 ` Al Viro
2012-06-08 22:40 ` Andrew Morton
2012-06-08 23:32 ` Kirill A. Shutemov
2012-06-08 23:31 ` Kirill A. Shutemov
2012-06-08 23:31 ` Kirill A. Shutemov
2012-06-08 23:37 ` Andrew Morton
2012-06-08 23:37 ` [Ocfs2-devel] " Andrew Morton
2012-06-08 23:37 ` Andrew Morton
2012-06-08 23:37 ` Andrew Morton
2012-06-08 23:46 ` Linus Torvalds
2012-06-08 23:46 ` [Ocfs2-devel] " Linus Torvalds
2012-06-08 23:46 ` Linus Torvalds
2012-06-09 0:28 ` Andrew Morton
2012-06-09 0:28 ` [Ocfs2-devel] " Andrew Morton
2012-06-09 0:28 ` Andrew Morton
2012-06-09 7:06 ` Marco Stornelli
2012-06-09 7:06 ` [Ocfs2-devel] " Marco Stornelli
2012-06-09 7:06 ` Marco Stornelli
2012-06-09 7:06 ` Marco Stornelli
[not found] ` <4FD2F5F4.1000106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-06-09 7:25 ` Andrew Morton
2012-06-09 7:25 ` [Ocfs2-devel] " Andrew Morton
2012-06-09 7:25 ` Andrew Morton
2012-06-09 7:25 ` Andrew Morton
2012-06-11 9:16 ` Kirill A. Shutemov
2012-06-11 9:16 ` Kirill A. Shutemov
2012-06-11 9:16 ` Kirill A. Shutemov
2012-06-08 23:28 ` Kirill A. Shutemov
2012-06-08 23:28 ` Kirill A. Shutemov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120608152550.258d6a30.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bharrosh@panasas.com \
--cc=boyu.mt@taobao.com \
--cc=ceph-devel@vger.kernel.org \
--cc=codalist@TELEMANN.coda.cs.cmu.edu \
--cc=ecryptfs@vger.kernel.org \
--cc=fuse-devel@lists.sourceforge.net \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=kirill.shutemov@linux.intel.com \
--cc=ldv@altlinux.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=linux-ntfs-dev@lists.sourceforge.net \
--cc=logfs@logfs.org \
--cc=npiggin@kernel.dk \
--cc=ocfs2-devel@oss.oracle.com \
--cc=osd-dev@open-osd.org \
--cc=reiserfs-devel@vger.kernel.org \
--cc=samba-technical@lists.samba.org \
--cc=torvalds@linux-foundation.org \
--cc=v9fs-developer@lists.sourceforge.net \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.