linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
	"Chen, Tim C" <tim.c.chen@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Davidlohr Bueso <dbueso@suse.de>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Jason Low <jason.low2@hp.com>,
	Michel Lespinasse <walken@google.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Waiman Long <waiman.long@hp.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: performance delta after VFS i_mutex=>i_rwsem conversion
Date: Tue, 7 Jun 2016 02:19:50 +0100	[thread overview]
Message-ID: <20160607011950.GK14480@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFw9g1A77L0hXY1PiwY0Anibx7suAu8i0C90mEbOEr_uqw@mail.gmail.com>

On Mon, Jun 06, 2016 at 05:58:53PM -0700, Linus Torvalds wrote:
> >From your description, you seem to be very confused about what "child
> == NULL" means. Here it means that it's a cursor to the beginning, but
> in your commentary on move_cursor(), you say "moves cursor immediately
> past child *or* to the very end if child is NULL".
> 
> That's very confusing. Is NULL beginning or end?

The former for argument, the latter for return value...

> >         unsigned *seq = &parent->d_inode->i_dir_seq, n;
> >         do {
> >                 int i = count;
> >                 n = smp_load_acquire(seq) & ~1;
> >                 rcu_read_lock();
> >                 do {
> >                         p = p->next;
> >                         if (p == &parent->d_subdirs) {
> >                                 child = NULL;
> >                                 break;
> >                         }
> 
> look, here you return NULL for "end" again. Even though it meant
> beginning at the start of the function. Nasty.

Actually, reassigning 'child' here was broken, NULL or no NULL - we want
the subsequent retries (if any) to start at the same state.
 
> Also, may I suggest that there is a very trivial special case for
> "next_positive()" that needs no barriers or sequence checking or
> anything else: at the very beginning, just load the "->next" pointer,
> and if it's a positive entry, you're done. That's going to be the
> common case when there _isn't_ crazy multi-threaded readdirs going on,
> so it's worth handling separately.

Point.

> In fact, if you have a special value for the case of "cursor is at
> end" situation, then for the small directory case that can be handled
> with a single getdents call, you'll *never* set the cursor in the
> child list at all, which means that the above special case for
> next_positive() is actually the common case even for the threaded
> situation.

Not really.  Cursor is allocated on the child list in the first place; it's
just that its position is ignored for file->f_pos <= 2.  We could change
that, but I'd rather avoid the headache right now.

      reply	other threads:[~2016-06-07  1:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06 20:00 performance delta after VFS i_mutex=>i_rwsem conversion Dave Hansen
2016-06-06 20:46 ` Linus Torvalds
2016-06-06 21:13   ` Waiman Long
2016-06-06 21:20     ` Linus Torvalds
2016-06-07  3:22       ` Valdis.Kletnieks
2016-06-07 15:22         ` Waiman Long
2016-06-08  8:58     ` Ingo Molnar
2016-06-09 10:25       ` Ingo Molnar
2016-06-09 18:14         ` Dave Hansen
2016-06-09 20:10           ` Chen, Tim C
2016-06-06 21:15   ` Al Viro
2016-06-06 21:46     ` Linus Torvalds
2016-06-06 22:07       ` Al Viro
2016-06-06 23:50         ` Linus Torvalds
2016-06-06 23:59           ` Linus Torvalds
2016-06-07  0:29             ` Linus Torvalds
2016-06-07  0:40           ` Al Viro
2016-06-07  0:44             ` Al Viro
2016-06-07  0:58             ` Al Viro
2016-06-07  0:58             ` Linus Torvalds
2016-06-07  1:19               ` Al Viro [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=20160607011950.GK14480@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=dave.hansen@intel.com \
    --cc=dbueso@suse.de \
    --cc=jason.low2@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=tim.c.chen@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=waiman.long@hp.com \
    --cc=walken@google.com \
    /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).