From: Dave Chinner <david@fromorbit.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] vfs.git - including i_mutex wrappers
Date: Sun, 24 Jan 2016 18:17:37 +1100 [thread overview]
Message-ID: <20160124071737.GM6033@dastard> (raw)
In-Reply-To: <20160124012002.GU17997@ZenIV.linux.org.uk>
On Sun, Jan 24, 2016 at 01:20:02AM +0000, Al Viro wrote:
> On Sun, Jan 24, 2016 at 11:26:58AM +1100, Dave Chinner wrote:
>
> > That's fair enough. However, compare this to how core locking
> > changes occur in the mm subsystem - they go through multiple patch
> > postings and review so there's no surprise when the pull request
> > comes.
>
> ... and the thread in question has grown from precisely that (and not the first
> iteration, either) for earlier such change (RCU symlinks). Subsequent one
> (follow_link -> get_link, with RCU symlink traversal for non-embedded
> symlinks) also went through fsdevel mailbombs (a couple of iterations, IIRC).
I haven't been following them closely, either, because it's
something I haven't needed to care much about. There's way more that
goes on than I can follow, but I would have expected something like
a pending i_mutex change to at least have a standalone "heads-up"
to inform various developers that they is a significant change
coming...
> Speaking of the earlier changes - IIRC, there had been plans to start
> hashing (at least some of) XFS symlinks. I think it was from hch, along
> the lines of "stash a buffer with symlink body into ->i_link the first time
> around, free it from inode eviction".
No idea - there hasn't been any followup, and nobody is telling me
they have a symlink traversal performance problem, so it's way off
my radar. I don't even know what workload RCU symlinks is supposed
to optimise....
> As long as that freeing is RCU-delayed,
> doing so would work just fine and give you symlink traversal without dropping
> from RCU mode... OTOH, if that gets resurrected, it probably ought to go
> through XFS tree - all VFS infrastructure is there (since 4.2), so it's
> purely XFS business at this point... One thing to watch out for is that
> RCU delay - see shmem.c fix in the same pull request for related example.
I can't see me getting to this in the next few months, to tell you
the truth. There's way more important things we need to do in XFS
land right now (like merge and stabilise reflink, reverse mapping,
DAX, etc), so this is likely to sit until someone who really needs
it comes along.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2016-01-24 7:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-23 14:58 [git pull] vfs.git - including i_mutex wrappers Al Viro
2016-01-23 22:34 ` Dave Chinner
2016-01-23 22:44 ` Dave Chinner
2016-01-23 23:09 ` Al Viro
2016-01-23 23:38 ` Al Viro
2016-01-24 0:53 ` Dave Chinner
2016-01-24 1:41 ` Al Viro
2016-01-24 7:04 ` Dave Chinner
2016-01-24 7:48 ` Al Viro
2016-01-23 23:48 ` Linus Torvalds
2016-01-24 0:26 ` Dave Chinner
2016-01-24 1:20 ` Al Viro
2016-01-24 7:17 ` Dave Chinner [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=20160124071737.GM6033@dastard \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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).