Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932952Ab3EBTg1 (ORCPT ); Thu, 2 May 2013 15:36:27 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:39889 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932712Ab3EBTg0 (ORCPT ); Thu, 2 May 2013 15:36:26 -0400 Date: Thu, 2 May 2013 12:34:09 -0700 From: "Paul E. McKenney" To: Julian Anastasov Cc: Peter Zijlstra , 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: <20130502193409.GA3780@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20130430072944.GA13959@verge.net.au> <20130501091012.GB28253@dyad.programming.kicks-ass.net> <20130501155501.GB7521@dyad.programming.kicks-ass.net> <20130502072623.GE7521@dyad.programming.kicks-ass.net> <20130502173257.GX3780@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13050219-2398-0000-0000-000013F7ADB1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2914 Lines: 76 On Thu, May 02, 2013 at 09:55:54PM +0300, Julian Anastasov wrote: > > Hello, > > On Thu, 2 May 2013, Paul E. McKenney wrote: > > > On Thu, May 02, 2013 at 06:54:05PM +0300, Julian Anastasov wrote: > > > > > > I tested the following patch in 2 variants, > > > TINY_RCU and CONFIG_TREE_PREEMPT_RCU. I see the > > > > Could you please also try CONFIG_TREE_RCU? > > Note that I'm testing on some 9-year old > UP system, i.e. 1 CPU. Now I enabled SMP to test CONFIG_TREE_RCU > and the results are same. I think, it should be just like > the TINY_RCU in terms of these debuggings (non-preempt). Extra > rcu_read_lock gives me "Illegal context switch in RCU read-side > critical section" in addition to the "BUG: sleeping function > called from invalid context" message. OK... > > > error if extra rcu_read_lock is added for testing. > > > > > > I'm using the PREEMPT_ACTIVE flag to indicate > > > that we are already under lock. It should work because > > > __might_sleep is not called with such bit. I also tried to > > > add new flag in include/linux/hardirq.h but PREEMPT_ACTIVE > > > depends on the arch, so this alternative looked difficult to > > > implement. > > > > +extern int __cond_resched_rcu(void); > > > + > > > +#define cond_resched_rcu() ({ \ > > > + __might_sleep(__FILE__, __LINE__, PREEMPT_ACTIVE | \ > > > + PREEMPT_RCU_OFFSET); \ > > > + __cond_resched_rcu(); \ > > > +}) > > > + > > > > @@ -7062,7 +7076,9 @@ void __might_sleep(const char *file, int line, int preempt_offset) > > > { > > > static unsigned long prev_jiffy; /* ratelimiting */ > > > > > > - rcu_sleep_check(); /* WARN_ON_ONCE() by default, no rate limit reqd. */ > > > + /* WARN_ON_ONCE() by default, no rate limit reqd. */ > > > + rcu_sleep_check(preempt_offset & PREEMPT_ACTIVE); > > > > Color me confused. > > > > >From what I can see, the two values passed in through preempt_offset > > are PREEMPT_LOCK_OFFSET and SOFTIRQ_DISABLE_OFFSET. PREEMPT_ACTIVE > > is normally a high-order bit, above PREEMPT_MASK, SOFTIRQ_MASK, and > > HARDIRQ_MASK. > > > > PREEMPT_LOCK_OFFSET and SOFTIRQ_DISABLE_OFFSET have only low-order bits, > > so I don't see how rcu_sleep_check() is passed anything other than zero. > > Am I going blind, or what? > > Only the new cond_resched_rcu() macro provides > PREEMPT_ACTIVE flag to skip the rcu_preempt_sleep_check() > call. The old macros provide locked=0 as you noticed. Does it > answer your question or I'm missing something? PREEMPT_ACTIVE's value is usually 0x10000000. Did it change since 3.9? If not, rcu_sleep_check(preempt_offset & PREEMPT_ACTIVE) is the same as rcu_sleep_check(0). 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/