From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932642Ab3EAQCr (ORCPT ); Wed, 1 May 2013 12:02:47 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:35600 "EHLO e7.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756889Ab3EAQCh (ORCPT ); Wed, 1 May 2013 12:02:37 -0400 Date: Wed, 1 May 2013 09:02:18 -0700 From: "Paul E. McKenney" To: Eric Dumazet Cc: Peter Zijlstra , Julian Anastasov , Simon Horman , 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: <20130501160218.GQ3780@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> <20130501124637.GO3780@linux.vnet.ibm.com> <20130501151752.GA7521@dyad.programming.kicks-ass.net> <1367422195.11020.46.camel@edumazet-glaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1367422195.11020.46.camel@edumazet-glaptop> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13050116-5806-0000-0000-000020F528B5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 01, 2013 at 08:29:55AM -0700, Eric Dumazet wrote: > On Wed, 2013-05-01 at 17:17 +0200, Peter Zijlstra wrote: > > On Wed, May 01, 2013 at 05:46:37AM -0700, Paul E. McKenney wrote: > > > > > 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. > > > > Hmm.. if that were the goal I'd like it to have a different name; > > cond_resched*() has always been about preemption. > > BTW, I do not remember why cond_resched() is not an empty macro > when CONFIG_PREEMPT=y ? My guess would be for the case where sched_preempt_enable_no_resched() is followed some time later by cond_resched(). Thanx, Paul