From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752532AbcFGBUN (ORCPT ); Mon, 6 Jun 2016 21:20:13 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:45672 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751882AbcFGBUM (ORCPT ); Mon, 6 Jun 2016 21:20:12 -0400 Date: Tue, 7 Jun 2016 02:19:50 +0100 From: Al Viro To: Linus Torvalds Cc: Dave Hansen , "Chen, Tim C" , Ingo Molnar , Davidlohr Bueso , "Peter Zijlstra (Intel)" , Jason Low , Michel Lespinasse , "Paul E. McKenney" , Waiman Long , LKML Subject: Re: performance delta after VFS i_mutex=>i_rwsem conversion Message-ID: <20160607011950.GK14480@ZenIV.linux.org.uk> References: <5755D671.9070908@intel.com> <20160606211522.GF14480@ZenIV.linux.org.uk> <20160606220753.GG14480@ZenIV.linux.org.uk> <20160607004058.GH14480@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.