Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964860AbbDUU5o (ORCPT ); Tue, 21 Apr 2015 16:57:44 -0400 Received: from mail-ie0-f171.google.com ([209.85.223.171]:36276 "EHLO mail-ie0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933027AbbDUU5m (ORCPT ); Tue, 21 Apr 2015 16:57:42 -0400 Message-ID: <1429649860.18561.7.camel@edumazet-glaptop2.roam.corp.google.com> Subject: Re: [RFC PATCH] fs: use a sequence counter instead of file_lock in fd_install From: Eric Dumazet To: Mateusz Guzik Cc: Al Viro , Andrew Morton , "Paul E. McKenney" , Yann Droneaud , Konstantin Khlebnikov , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 21 Apr 2015 13:57:40 -0700 In-Reply-To: <20150421200624.GA16097@mguzik> References: <20150416121628.GA20615@mguzik> <1429307216.7346.255.camel@edumazet-glaptop2.roam.corp.google.com> <20150417221646.GA15589@mguzik> <20150417230252.GE889@ZenIV.linux.org.uk> <20150420130633.GA2513@mguzik> <20150420134326.GC2513@mguzik> <20150420151054.GD2513@mguzik> <1429550126.7346.268.camel@edumazet-glaptop2.roam.corp.google.com> <1429562991.7346.290.camel@edumazet-glaptop2.roam.corp.google.com> <1429639543.7346.329.camel@edumazet-glaptop2.roam.corp.google.com> <20150421200624.GA16097@mguzik> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2340 Lines: 79 On Tue, 2015-04-21 at 22:06 +0200, Mateusz Guzik wrote: > On Tue, Apr 21, 2015 at 11:05:43AM -0700, Eric Dumazet wrote: > > 3) I avoid multiple threads doing a resize and then only one wins the > > deal. > > > > One could argue this last bit could be committed separately (a different > logical change). Not really. The prior code was fine, but the addition of synchronize_sched() made the overhead much bigger in case multiple threads do this at the same time. > > As I read up about synchronize_sched and rcu_read_lock_sched, the code > should be correct. > > spin_lock(&files->file_lock); > > if (!new_fdt) > > return -ENOMEM; > > @@ -170,9 +173,12 @@ static int expand_fdtable(struct files_struct *files, int nr) > > if (cur_fdt != &files->fdtab) > > call_rcu(&cur_fdt->rcu, free_fdtable_rcu); > > } else { > > + WARN_ON_ONCE(1); > > /* Somebody else expanded, so undo our attempt */ > > __free_fdtable(new_fdt); > > The reader may be left confused why there is a warning while the comment > does not indicate anything is wrong. My intent is to remove completely this code, but I left this WARN_ON_ONCE() for my tests, just to make sure my theory was right ;) > > > } > > + /* coupled with smp_rmb() in __fd_install() */ > > + smp_wmb(); > > return 1; > > } > > > > @@ -187,19 +193,33 @@ static int expand_fdtable(struct files_struct *files, int nr) > > static int expand_files(struct files_struct *files, int nr) > > { > > struct fdtable *fdt; > > + int expanded = 0; > > > > +begin: > > fdt = files_fdtable(files); > > > > /* Do we need to expand? */ > > if (nr < fdt->max_fds) > > - return 0; > > + return expanded; > > > > /* Can we expand? */ > > if (nr >= sysctl_nr_open) > > return -EMFILE; > > > > + while (unlikely(files->resize_in_progress)) { > > + spin_unlock(&files->file_lock); > > + expanded = 1; > > + wait_event(files->resize_wait, !files->resize_in_progress); > > + spin_lock(&files->file_lock); > > + goto begin; > > + } > > This does not loop anymore, so s/while/if/ ? You are right, thanks ! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/