Hello, On Wed, 1 May 2013, 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: > > > > > 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? > > That is; the thing that makes sense to me is: > > static void inline cond_resched_rcu_lock(void) > { > #ifdef CONFIG_PREEMPT_RCU You mean '#ifndef' here, right? But in the non-preempt case is using the need_resched() needed? rcu_read_unlock and rcu_read_lock do not generate code. > 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. I see. So, can we choose one of both variants: 1. Your variant but with ifndef: static void inline cond_resched_rcu_lock(void) { #ifndef CONFIG_PREEMPT_RCU if (need_resched()) { rcu_read_unlock(); cond_resched(); rcu_read_lock(); } #endif } 2. Same without need_resched because cond_resched already performs the same checks: static void inline cond_resched_rcu_lock(void) { #ifndef CONFIG_PREEMPT_RCU rcu_read_unlock(); cond_resched(); rcu_read_lock(); #endif } Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html