From: Nick Piggin <npiggin@suse.de>
To: Greg KH <gregkh@suse.de>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Frank Mayhar <fmayhar@google.com>,
John Stultz <johnstul@us.ibm.com>,
Andi Kleen <ak@linux.intel.com>,
linux-fsdevel@vger.kernel.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [patch 1/2] fs: cleanup files_lock
Date: Thu, 18 Mar 2010 01:38:26 +1100 [thread overview]
Message-ID: <20100317143826.GM2869@laptop> (raw)
In-Reply-To: <20100317141602.GA26661@suse.de>
On Wed, Mar 17, 2010 at 07:16:02AM -0700, Greg KH wrote:
> On Tue, Mar 16, 2010 at 08:44:23PM +1100, Nick Piggin wrote:
> > I would like to start sending bits of vfs scalability improvements to
> > be reviewed and hopefully merged.
> >
> > I will start with files_lock. Last time this one came up, it was
> > criticised because some hoped to get rid of files list, and because
> > it didn't have enough justification of the scalability improvement.
> >
> > For the first criticism, it isn't any more difficult to rip out if
> > we are ever able to remove files list. For the second, I have gathered
> > some statistics and written better justification. Andi I believe is
> > finding kbuild is becoming limited by files lock on larger systems.
> >
> > --
> >
> > fs: cleanup files_lock
> >
> > Lock tty_files with a new spinlock, tty_files_lock; provide helpers to
> > manipulate the per-sb files list; unexport the files_lock spinlock.
> >
> > Signed-off-by: Nick Piggin <npiggin@suse.de>
>
> Looks good to me.
So long as the tty file always gets removed before file_sb_list_del
in __fput or put_filp. Otherwise file_sb_list_del would use the wrong
lock for it. As far as I could see, it should always get removed by
tty_release.
> Do you want me to apply this to my tty tree, or do
> you want to take it through your tree because your other patch depends
> on this?
>
> If you want to do it, feel free to add:
> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
> to the patch.
If they aren't both applied to -vfs tree in this round I'll ask you to
apply this one.
Thanks,
Nick
next prev parent reply other threads:[~2010-03-17 14:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-16 9:44 [patch 1/2] fs: cleanup files_lock Nick Piggin
2010-03-16 9:46 ` [patch 2/2] fs: scale files_lock Nick Piggin
2010-03-16 14:41 ` [patch 1/2] fs: cleanup files_lock Andi Kleen
2010-03-17 14:16 ` Greg KH
2010-03-17 14:38 ` Nick Piggin [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-09-04 6:51 [patch 00/33] my current vfs scalability patch queue npiggin
2009-09-04 6:51 ` [patch 03/33] fs: scale files_lock npiggin
2009-09-28 13:24 ` Peter Zijlstra
2009-10-01 2:16 ` Nick Piggin
[not found] ` <r2i3282373b1004011751j440635b3n484018db2e2bc50c@mail.gmail.com>
2010-04-02 2:24 ` [patch 1/2] fs: cleanup files_lock tim
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=20100317143826.GM2869@laptop \
--to=npiggin@suse.de \
--cc=ak@linux.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ebiederm@xmission.com \
--cc=fmayhar@google.com \
--cc=gregkh@suse.de \
--cc=johnstul@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--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).