Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755671Ab3EAMqv (ORCPT ); Wed, 1 May 2013 08:46:51 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:60915 "EHLO e9.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751667Ab3EAMqp (ORCPT ); Wed, 1 May 2013 08:46:45 -0400 Date: Wed, 1 May 2013 05:46:37 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Julian Anastasov , Simon Horman , Eric Dumazet , Ingo Molnar , lvs-devel@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, linux-kernel@vger.kernel.org, Pablo Neira Ayuso , Dipankar Sarma Subject: Re: [PATCH v2 1/2] sched: Add cond_resched_rcu_lock() helper Message-ID: <20130501124637.GO3780@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1367290378-29224-1-git-send-email-horms@verge.net.au> <1367290378-29224-2-git-send-email-horms@verge.net.au> <20130430072944.GA13959@verge.net.au> <20130501091012.GB28253@dyad.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130501091012.GB28253@dyad.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13050112-7182-0000-0000-0000067C7655 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1897 Lines: 62 On Wed, May 01, 2013 at 11:10:12AM +0200, Peter Zijlstra wrote: > On Tue, Apr 30, 2013 at 10:52:38AM +0300, Julian Anastasov wrote: > > > > Hello, > > > > On Tue, 30 Apr 2013, Simon Horman wrote: > > > > > > > +static void inline cond_resched_rcu_lock(void) > > > > > +{ > > > > > + if (need_resched()) { > > > > > > > > Ops, it should be without above need_resched. > > > > > > Thanks, to clarify, just this: > > > > > > static void inline cond_resched_rcu_lock(void) > > > { > > > rcu_read_unlock(); > > > #ifndef CONFIG_PREEMPT_RCU > > > cond_resched(); > > > #endif > > > rcu_read_lock(); > > > } > > > > Yes, thanks! > > OK, now I'm confused.. PREEMPT_RCU would preempt in any case, so why bother > dropping rcu_read_lock() at all? Good point, I was assuming that the goal was to let grace periods end as well as to allow preemption. The momentary dropping out of the RCU read-side critical section allows the grace periods to end. > That is; the thing that makes sense to me is: > > static void inline cond_resched_rcu_lock(void) > { > #ifdef CONFIG_PREEMPT_RCU > if (need_resched()) { > rcu_read_unlock(); > cond_resched(); > rcu_read_lock(); > } > #endif /* CONFIG_PREEMPT_RCU */ > } > > That would have an rcu_read_lock() break and voluntary preemption point for > non-preemptible RCU and not bother with the stuff for preemptible RCU. If the only goal is to allow preemption, and if long grace periods are not a concern, then this alternate approach would work fine as well. Of course, both approaches assume that the caller is in a place where having all RCU-protected data disappear is OK! Thanx, Paul -- 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/