From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless
 update of refcount
Date: Fri, 30 Aug 2013 21:26:08 +0100
Message-ID: <20130830202608.GD13318@ZenIV.linux.org.uk>
References: <CA+55aFwzY_1tD5vmaDgwAGLXNSGw4XS8vEp9vOpN6NPm5+Mxow@mail.gmail.com>
 <CA+55aFx1oq7+jce8vLWRitASVMugCojYe3gmhXwhLx4K9Au3XQ@mail.gmail.com>
 <CA+55aFyq7dJnm6tfn12hLOw5qKLW2RXRFERHgZO-sOOnUmjd3g@mail.gmail.com>
 <52200DAE.2020303@hp.com>
 <CA+55aFyhTR15GBS4VNoRkcFyubEJU7a+Pzd-6VZeKoU8qB0q5Q@mail.gmail.com>
 <5220E56A.80603@hp.com>
 <CA+55aFzv9BZ2+B2NrNRRtTqnfgbH3LRSvSsUZVsy-g9OpM-8HA@mail.gmail.com>
 <5220F090.5050908@hp.com>
 <20130830194059.GC13318@ZenIV.linux.org.uk>
 <5220F811.9060902@hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Jeff Layton <jlayton@redhat.com>,
	Miklos Szeredi <mszeredi@suse.cz>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andi Kleen <andi@firstfloor.org>,
	"Chandramouleeswaran, Aswin" <aswin@hp.com>,
	"Norton, Scott J" <scott.norton@hp.com>
To: Waiman Long <waiman.long@hp.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <5220F811.9060902@hp.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Fri, Aug 30, 2013 at 03:52:49PM -0400, Waiman Long wrote:

> So it is the mnput_no_expire() function that is doing all the
> lg_global_lock() calls.

Interesting...  So you are getting a lot of mntput() with ->mnt_ns being
NULL?  I wonder which type it is...  Note that anything mounted will
have non-NULL ->mnt_ns until umount and anything obtained via
kern_mount/kern_mount_data will also have a non-NULL ->mnt_ns - until
kern_unmount().

Could you try to gather stats of that sort?  Normally that path should
be only hit by fput() when we have a lazy-unmounted fs and close an opened
file on it...

I see one potential stupidity in that area (simple_pin_fs() ought to set
->mnt_ns, with simple_release_fs() clearing it), but there's not a lot
of fs types that would use the damn thing...