From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753766AbcGURe2 (ORCPT ); Thu, 21 Jul 2016 13:34:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53451 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753582AbcGUReZ (ORCPT ); Thu, 21 Jul 2016 13:34:25 -0400 Date: Thu, 21 Jul 2016 19:34:36 +0200 From: Oleg Nesterov To: "Paul E. McKenney" Cc: Peter Zijlstra , mingo@kernel.org, linux-kernel@vger.kernel.org, tj@kernel.org, john.stultz@linaro.org, dimitrysh@google.com, romlem@google.com, ccross@google.com, tkjos@google.com Subject: Re: [PATCH] rcu_sync: simplify the state machine, introduce __rcu_sync_enter() Message-ID: <20160721173435.GB22488@redhat.com> References: <20160715132709.GA27644@redhat.com> <20160715133928.GH7094@linux.vnet.ibm.com> <20160715134523.GB28589@redhat.com> <20160715153840.GI7094@linux.vnet.ibm.com> <20160715164938.GA4294@redhat.com> <20160715180140.GM7094@linux.vnet.ibm.com> <20160716171007.GA30000@redhat.com> <20160719205018.GB7094@linux.vnet.ibm.com> <20160720171602.GA5059@redhat.com> <20160720213144.GM7094@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160720213144.GM7094@linux.vnet.ibm.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 21 Jul 2016 17:34:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/20, Paul E. McKenney wrote: > > On Wed, Jul 20, 2016 at 07:16:03PM +0200, Oleg Nesterov wrote: > > > Now, suppose we add the additional enter/exit's: > > > > freeze_super(sb) > > { > > // this doesn't block > > __rcu_sync_enter(SEM3); > > __rcu_sync_enter(SEM2); > > __rcu_sync_enter(SEM1); > > > > down_write(&sb->s_umount); > > if (NEED_TO_FREEZE) { > > percpu_down_write(SEM1); > > The above waits for the grace period initiated by __rcu_sync_enter(), > correct? Presumably "yes", because it will invoke rcu_sync_enter(), which > will see the state as GP_ENTER, and will thus wait. But if down_write() blocks and/or NEED_TO_FREEZE takes some time it could already see the GP_PASSED state, or at least it can sleep less. > But your point is that if !NEED_TO_FREEZE, we will get here without > waiting for a grace period. > > But why aren't the __rcu_sync_enter() and rcu_sync_exit() calls inside > the "if" statement? Yes, if we do __rcu_sync_enter() inside "if", then rcu_sync_exit() can't hit GP_ENTER. But why we should disallow this use-case? It does not complicate the code at all. And see above, we want to initiate the GP "asap", so that we will sleep less later. Although yes, freeze_super() is not the best example. And __cgroup_procs_write() too, but note that cgroup_kn_lock_live() is rather heavy, takes the global locks, and can fail. So (ignoring the fact we are going to switch cgroup_threadgroup_rwsem into the slow mode for now) __rcu_sync_enter() at the start could help to lessen the time percpu_down_write(cgroup_threadgroup_rwsem) sleeps with the cgroup_mutex held. > That aside, would it make sense to name __rcu_sync_enter() something > like rcu_sync_begin_to_enter(), rcu_sync_pre_enter() or some such? > Something to make it clear that it just starts the job and that something > else is needed to finish it. Sure. Agreed, will rename. > And here is an updated state table. I do not yet separately call out > __rcu_sync_enter(), though without it the rcu_sync_exit() transition > out of state B cannot happen. Thanks! I'll try to double-check it. Oleg.