From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
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: Sat, 9 Jun 2012 02:28:11 +0300 [thread overview]
Message-ID: <20120608232811.GA18981@otc-wbsnb-06> (raw)
In-Reply-To: <20120608152550.258d6a30.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]
On Fri, Jun 08, 2012 at 03:25:50PM -0700, Andrew Morton wrote:
> 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.
ALT Linux guys use a namespaces (including IPC namespace) to create
sandbox[1] for build system and other use cases. The build system calls
the sandboxing wrapper frequently on setup building chroot and build
prepare. This kind of delays affect timings significantly.
[1] http://git.altlinux.org/people/ldv/packages/hasher-priv.git
> > > 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.
Call Trace:
[<ffffffff81443a2a>] schedule+0x3a/0x50
[<ffffffff81441e7d>] schedule_timeout+0x1cd/0x2c0
[<ffffffff811f8f87>] ? mqueue_destroy_inode+0x17/0x20
[<ffffffff81443044>] wait_for_common+0xc4/0x160
[<ffffffff8107af50>] ? try_to_wake_up+0x2a0/0x2a0
[<ffffffff810d63b0>] ? call_rcu_sched+0x10/0x20
[<ffffffff810d63a0>] ? call_rcu_bh+0x20/0x20
[<ffffffff81443188>] wait_for_completion+0x18/0x20
[<ffffffff810d5a9b>] _rcu_barrier.clone.31+0x9b/0xb0
[<ffffffff810d5ac0>] rcu_barrier_sched+0x10/0x20
[<ffffffff810d5ad9>] rcu_barrier+0x9/0x10
[<ffffffff811602c9>] deactivate_locked_super+0x49/0x90
[<ffffffff81160d35>] deactivate_super+0x45/0x60
[<ffffffff8117ad74>] mntput_no_expire+0x104/0x150
[<ffffffff8117addc>] mntput+0x1c/0x30
[<ffffffff8117cda7>] kern_unmount+0x27/0x30
[<ffffffff811faeb0>] mq_put_mnt+0x10/0x20
[<ffffffff811fb57f>] put_ipc_ns+0x3f/0xb0
[<ffffffff81071f5c>] free_nsproxy+0x3c/0xa0
[<ffffffff81072143>] switch_task_namespaces+0x33/0x40
[<ffffffff8107215b>] exit_task_namespaces+0xb/0x10
[<ffffffff8104f154>] do_exit+0x4b4/0x8a0
[<ffffffff8104f7e3>] do_group_exit+0x53/0xc0
[<ffffffff8104f862>] sys_exit_group+0x12/0x20
[<ffffffff8144c939>] system_call_fastpath+0x16/0x1b
--
Kirill A. Shutemov
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-06-08 23:26 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 ` [RFC, PATCH] " Kirill A. Shutemov
2012-06-08 22:06 ` 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 [this message]
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=20120608232811.GA18981@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 \
--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 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).