Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1415615

Re: performance delta after VFS i_mutex=>i_rwsem conversion

From Al Viro <viro@ZenIV.linux.org.uk>
Newsgroups linux.kernel
Subject Re: performance delta after VFS i_mutex=>i_rwsem conversion
Date 2016-06-07 03:30 +0200
Message-ID <rHe09-4kp-3@gated-at.bofh.it> (permalink)
References (3 earlier) <rHazf-1ZA-19@gated-at.bofh.it> <rHaSB-2px-9@gated-at.bofh.it> <rHcB4-3jH-5@gated-at.bofh.it> <rHdnr-3O5-5@gated-at.bofh.it> <rHdx7-3Ri-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

performance delta after VFS i_mutex=>i_rwsem conversion Dave Hansen <dave.hansen@intel.com> - 2016-06-06 22:10 +0200
  Re: performance delta after VFS i_mutex=>i_rwsem conversion Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-06 22:50 +0200
    Re: performance delta after VFS i_mutex=>i_rwsem conversion Al Viro <viro@ZenIV.linux.org.uk> - 2016-06-06 23:20 +0200
      Re: performance delta after VFS i_mutex=>i_rwsem conversion Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-06 23:50 +0200
        Re: performance delta after VFS i_mutex=>i_rwsem conversion Al Viro <viro@ZenIV.linux.org.uk> - 2016-06-07 00:10 +0200
          Re: performance delta after VFS i_mutex=>i_rwsem conversion Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-07 02:00 +0200
            Re: performance delta after VFS i_mutex=>i_rwsem conversion Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-07 02:00 +0200
              Re: performance delta after VFS i_mutex=>i_rwsem conversion Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-07 02:30 +0200
            Re: performance delta after VFS i_mutex=>i_rwsem conversion Al Viro <viro@ZenIV.linux.org.uk> - 2016-06-07 02:50 +0200
              Re: performance delta after VFS i_mutex=>i_rwsem conversion Al Viro <viro@ZenIV.linux.org.uk> - 2016-06-07 02:50 +0200
              Re: performance delta after VFS i_mutex=>i_rwsem conversion Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-07 03:00 +0200
                Re: performance delta after VFS i_mutex=>i_rwsem conversion Al Viro <viro@ZenIV.linux.org.uk> - 2016-06-07 03:30 +0200
              Re: performance delta after VFS i_mutex=>i_rwsem conversion Al Viro <viro@ZenIV.linux.org.uk> - 2016-06-07 03:00 +0200
    Re: performance delta after VFS i_mutex=>i_rwsem conversion Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-06 23:30 +0200
      Re: performance delta after VFS i_mutex=>i_rwsem conversion Valdis.Kletnieks@vt.edu - 2016-06-07 05:30 +0200
    Re: performance delta after VFS i_mutex=>i_rwsem conversion Ingo Molnar <mingo@kernel.org> - 2016-06-08 11:00 +0200
      Re: performance delta after VFS i_mutex=>i_rwsem conversion Ingo Molnar <mingo@kernel.org> - 2016-06-09 12:30 +0200
        Re: performance delta after VFS i_mutex=>i_rwsem conversion Dave Hansen <dave.hansen@intel.com> - 2016-06-09 20:20 +0200
          RE: performance delta after VFS i_mutex=>i_rwsem conversion "Chen, Tim C" <tim.c.chen@intel.com> - 2016-06-09 22:20 +0200

csiph-web