From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Boaz Harrosh <bharrosh@panasas.com>, Tao Ma <boyu.mt@taobao.com>,
Andrew Morton <akpm@linux-foundation.org>,
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] fs: push rcu_barrier() from deactivate_locked_super() to filesystems
Date: Sat, 9 Jun 2012 01:00:49 +0300 [thread overview]
Message-ID: <20120608220049.GA18024@otc-wbsnb-06> (raw)
In-Reply-To: <1339191663-17693-1-git-send-email-kirill.shutemov@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]
On Fri, Jun 08, 2012 at 02:43:58PM -0700, Linus Torvalds wrote:
> On Fri, Jun 8, 2012 at 2:28 PM, Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com> wrote:
> > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> >
> > 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?
When I tried SLAB_DESTROY_BY_RCU I've got problem:
[ 36.687999] Pid: 3455, comm: rmmod Not tainted 3.5.0-rc1-00130-g48d212a-dirty #40
[ 36.688001] Call Trace:
[ 36.688012] [<ffffffff8113367a>] slab_err+0xaa/0xd0
[ 36.688020] [<ffffffff8113515a>] ? __kmalloc+0x10a/0x110
[ 36.688026] [<ffffffff8113647d>] kmem_cache_destroy+0x1dd/0x420
[ 36.688056] [<ffffffffa00f0f25>] btrfs_destroy_cachep+0x15/0x60 [btrfs]
[ 36.688076] [<ffffffffa013cac3>] exit_btrfs_fs+0x9/0x3a [btrfs]
[ 36.688083] [<ffffffff810c324e>] sys_delete_module+0x16e/0x2f0
[ 36.688090] [<ffffffff8128cf29>] ? lockdep_sys_exit_thunk+0x35/0x67
[ 36.688097] [<ffffffff8161eba6>] system_call_fastpath+0x1a/0x1f
[ 36.688111] Pid: 3455, comm: rmmod Not tainted 3.5.0-rc1-00130-g48d212a-dirty #40
[ 36.688114] Call Trace:
[ 36.688119] [<ffffffff811365ee>] kmem_cache_destroy+0x34e/0x420
[ 36.688143] [<ffffffffa00f0f25>] btrfs_destroy_cachep+0x15/0x60 [btrfs]
[ 36.688162] [<ffffffffa013cac3>] exit_btrfs_fs+0x9/0x3a [btrfs]
[ 36.688168] [<ffffffff810c324e>] sys_delete_module+0x16e/0x2f0
[ 36.688174] [<ffffffff8128cf29>] ? lockdep_sys_exit_thunk+0x35/0x67
[ 36.688179] [<ffffffff8161eba6>] system_call_fastpath+0x1a/0x1f
IIUC, moving rcu_barrier() up should help, but I can't say that I fully
understand SLAB_DESTROY_BY_RCU semantics.
--
Kirill A. Shutemov
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-08 21:59 UTC|newest]
Thread overview: 19+ 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 22:00 ` Kirill A. Shutemov [this message]
2012-06-08 22:06 ` [RFC, PATCH] " Linus Torvalds
2012-06-08 22:25 ` Al Viro
2012-06-08 22:02 ` [RFC, PATCH, RESEND] " Andrew Morton
2012-06-08 22:14 ` Kirill A. Shutemov
2012-06-08 22:23 ` Al Viro
2012-06-08 22:27 ` Linus Torvalds
2012-06-08 22:25 ` Andrew Morton
2012-06-08 22:27 ` Al Viro
2012-06-08 22:31 ` Andrew Morton
2012-06-08 23:31 ` Kirill A. Shutemov
2012-06-08 23:37 ` Andrew Morton
2012-06-08 23:46 ` Linus Torvalds
2012-06-09 0:28 ` Andrew Morton
2012-06-09 7:06 ` Marco Stornelli
2012-06-09 7:25 ` Andrew Morton
2012-06-11 9:16 ` 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=20120608220049.GA18024@otc-wbsnb-06 \
--to=kirill.shutemov@linux.intel.com \
--cc=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=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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).