From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758497AbbEaQH7 (ORCPT ); Sun, 31 May 2015 12:07:59 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:43283 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758476AbbEaQH4 (ORCPT ); Sun, 31 May 2015 12:07:56 -0400 Date: Sun, 31 May 2015 09:07:50 -0700 From: "Paul E. McKenney" To: Oleg Nesterov Cc: Peter Zijlstra , tj@kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org, der.herr@hofr.at, dave@stgolabs.net, torvalds@linux-foundation.org Subject: Re: [RFC][PATCH 1/5] rcu: Create rcu_sync infrastructure Message-ID: <20150531160750.GK5989@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150526114356.609107918@infradead.org> <20150526120214.632757988@infradead.org> <20150530165810.GA14999@linux.vnet.ibm.com> <20150530191652.GA13956@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150530191652.GA13956@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15053116-0013-0000-0000-00000BB6F35E Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 30, 2015 at 09:16:52PM +0200, Oleg Nesterov wrote: > On 05/30, Paul E. McKenney wrote: > > > > On Tue, May 26, 2015 at 01:43:57PM +0200, Peter Zijlstra wrote: > > > From: Oleg Nesterov > > > > > > It is functionally equivalent to > > > > > > struct rcu_sync_struct { > > > atomic_t counter; > > > }; > > > > > > static inline bool rcu_sync_is_idle(struct rcu_sync_struct *rss) > > > { > > > return atomic_read(&rss->counter) == 0; > > > } > > > > > > static inline void rcu_sync_enter(struct rcu_sync_struct *rss) > > > { > > > atomic_inc(&rss->counter); > > > synchronize_sched(); > > > } > > > > For vanilla RCU, this is called get_state_synchronize_rcu(). > > > > > static inline void rcu_sync_exit(struct rcu_sync_struct *rss) > > > { > > > synchronize_sched(); > > > atomic_dec(&rss->counter); > > > } > > > > > > except: it records the state and synchronize_sched() is only called by > > > rcu_sync_enter() and only if necessary. > > > > Again for vanilla RCU, this is called cond_synchronize_rcu(). > > Hmm. I do not understand... I think rcu_sync doesn't need > get_state/cond_synchronize. > > The first caller of rcu_sync_enter() always needs sync(). The next one > could use cond_synchronize_rcu(), but for what? The 2nd one will wait > for the end of gp started by the first caller, and this is more optimal? > > Note that rcu_sync_enter/rcu_sync_func never call sync() unless strictly > necessary. > > Or I misunderstood you? Probably me forgetting exactly what your APIs above are doing. I clearly need to take a closer look when fully awake. ;-) Thanx, Paul