linux-kernel - Re: [vfs] 73c12e50a: +13349.5% softirqs.RCU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87ppmipu3z.fsf@xmission.com>
Date:	Wed, 19 Feb 2014 15:20:48 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Fengguang Wu <fengguang.wu@...el.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>
Subject: Re: [vfs] 73c12e50a: +13349.5% softirqs.RCU

Fengguang Wu <fengguang.wu@...el.com> writes:

> Hi Eric,
>
> FYI, we noticed the below changes on commit 73c12e50af3a756137071c1e1c1e99cffcbaa835
> ("vfs: Lazily remove mounts on unlinked files and directories."):
>     
> test case: dbench
>
> 5c39777e797e7ba  73c12e50af3a756137071c1e1  
> ---------------  -------------------------  
>       6.22 ~ 0%    +195.3%      18.36 ~18%  TOTAL dbench.max_latency
>
> Note: the "~ XX%" numbers are stddev percent.
>
> test case: will-it-scale/unlink2

Interesting.

So if I read this right dbench is taking much about twice as long in the
worst case with my patch, and you have some other numbers below that
indicate other variations in the workload.  Which as I read the numbers
looks like there is generally more sleeping going on.

There is one know silliness in my patch that could certainly cause this,
Fengguag could you test the incremental patch below and tell me if it
solves the regression in your numbers.

Eric

From: "Eric W. Biederman" <ebiederm@...ssion.com>
Date: Wed, 19 Feb 2014 15:00:20 -0800
Subject: [PATCH] vfs: Avoid taking the locks in detach_mounts when possible.

The common case is that there are no mounts to detach so keep
that case fast by testing d_mountpoint before taking calling
into detach_mounts and taking the namespace lock.

Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
---
 fs/mount.h     |    9 ++++++++-
 fs/namespace.c |    2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/fs/mount.h b/fs/mount.h
index 2b470f34e665..5f2579d1950c 100644
--- a/fs/mount.h
+++ b/fs/mount.h
@@ -84,7 +84,14 @@ extern struct mount *__lookup_mnt_last(struct vfsmount *, struct dentry *);
 
 extern bool legitimize_mnt(struct vfsmount *, unsigned);
 
-extern void detach_mounts(struct dentry *dentry);
+extern void __detach_mounts(struct dentry *dentry);
+
+static inline void detach_mounts(struct dentry *dentry)
+{
+	if (!d_mountpoint(dentry))
+		return;
+	__detach_mounts(dentry);
+}
 
 static inline void get_mnt_ns(struct mnt_namespace *ns)
 {
diff --git a/fs/namespace.c b/fs/namespace.c
index 7abbf722ce18..7b1466a82566 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1369,7 +1369,7 @@ static int do_umount(struct mount *mnt, int flags)
  * 
  * The caller may hold dentry->d_inode->i_mutex.
  */
-void detach_mounts(struct dentry *dentry)
+void __detach_mounts(struct dentry *dentry)
 {
 	struct mountpoint *mp;
 	struct mount *mnt;
-- 
1.7.5.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/