On Tue, Apr 15, 2014 at 06:29:51PM -0400, Dave Jones wrote:
> On Tue, Apr 15, 2014 at 03:17:55PM -0700, Paul E. McKenney wrote:
>
> > My current admittedly crude workaround is as follows:
> >
> > static inline bool rcu_should_resched(void)
> > {
> > int t;
> >
> > #ifdef CONFIG_DEBUG_PREEMPT
> > preempt_disable();
> > #endif /* #ifdef CONFIG_DEBUG_PREEMPT */
> > t = __this_cpu_read(rcu_cond_resched_count) + 1;
> > if (t < RCU_COND_RESCHED_LIM) {
> > __this_cpu_write(rcu_cond_resched_count, t);
> > #ifdef CONFIG_DEBUG_PREEMPT
> > preempt_enable();
> > #endif /* #ifdef CONFIG_DEBUG_PREEMPT */
> > return false;
> > }
> > #ifdef CONFIG_DEBUG_PREEMPT
> > preempt_enable();
> > #endif /* #ifdef CONFIG_DEBUG_PREEMPT */
> > return true;
> > }
>
> Won't using DEBUG_PREEMPT instead of just CONFIG_PREEMPT here make this
> silently do the wrong thing if preemption is enabled, but debugging isn't ?
If preemption is enabled, but debugging is not, then yes, the above code
might force an unnecessary schedule() if the above code was preempted
between the __this_cpu_read() and the __this_cpu_write(). Which does
not cause a problem, especially given that it won't happen very often.
> I'm not seeing why you need the ifdefs at all, unless the implied
> barrier() is a problem ?
I don't think that Peter Zijlstra would be too happy about an extra
unneeded preempt_disable()/preempt_enable() pair in the cond_resched()
fastpath. Not that I necessarily expect him to be particularly happy
with the above, but perhaps someone has a better approach.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
