On Fri, Jul 06, 2018 at 06:14:44PM +0100, David Woodhouse wrote: > On Fri, 2018-07-06 at 10:11 -0700, Paul E. McKenney wrote: > > > The preempt state is alread a bit complicated and shadowed in the > > > preempt_count (on some architectures) adding additional bits to it like > > > this is just asking for trouble. > > > > How about a separate need_resched_rcu() that includes the extra cache > > miss? Or open-coding the rcu_urgent_qs_requested()? > > Peter said "touch two cachelines". He didn't say it was a cache miss. > > Given that every single cond_resched() call touches the same cache > line, and every single rcu_all_qs() and similar will also touch it, > it's fairly much guaranteed *not* to be a miss...
cond_resched() is a no-op for PREEMPT=y, but then you're still sprinkling that read all across. > ... which is why I didn't really understand why he cared. Well it also complicated the whole preemption state, and like I wrote, TIF_NEED_RESCHED is not the only place we track preemption state in. Stuff like preempt_enable() will (on x86) only ever look at the preempt_count value.
