From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [patch 04/27] fs: introduce mnt_clone_write
Date: Sat, 25 Apr 2009 04:35:03 +0100
Message-ID: <20090425033503.GV8633@ZenIV.linux.org.uk>
References: <20090425012020.457460929@suse.de> <20090425012209.513109971@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Dave Hansen <haveblue@us.ibm.com>
To: npiggin@suse.de
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:37396 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752925AbZDYDfH (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 24 Apr 2009 23:35:07 -0400
Content-Disposition: inline
In-Reply-To: <20090425012209.513109971@suse.de>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sat, Apr 25, 2009 at 11:20:24AM +1000, npiggin@suse.de wrote:
> This patch speeds up lmbench lat_mmap test by about another 2% after the
> first patch.
> 
> Before:
>  avg = 462.286
>  std = 5.46106
> 
> After:
>  avg = 453.12
>  std = 9.58257
> 
> (50 runs of each, stddev gives a reasonable confidence)
> 
> It does this by introducing mnt_clone_write, which avoids some heavyweight
> operations of mnt_want_write if called on a vfsmount which we know already
> has a write count; and mnt_want_write_file, which can call mnt_clone_write
> if the file is open for write.
> 
> After these two patches, mnt_want_write and mnt_drop_write go from 7% on
> the profile down to 1.3% (including mnt_clone_write).

NAK in this form; nested mnt_want_write() *CAN* fail (note the check for
superblock itself being r/o).  Make you mnt_clone_write() returning int
and doing that superblock check, and I'm OK with it.