On Mon, Apr 23, 2018 at 05:40:00AM -0700, Paul E. McKenney wrote: > On Mon, Apr 23, 2018 at 10:51:27AM +0200, Peter Zijlstra wrote: > > On Sun, Apr 22, 2018 at 07:32:06PM -0700, Paul E. McKenney wrote: > > > In CONFIG_PREEMPT=y kernels, cond_resched() is a complete no-op, and > > > thus cannot help advance Tasks-RCU grace periods. However, such grace > > > periods are only an issue in non-production benchmarking runs of the > > > Linux kernel. This commit therefore makes cond_resched() invoke > > > rcu_note_voluntary_context_switch() for kernels implementing Tasks RCU > > > even in CONFIG_PREEMPT=y kernels. > > > > I'm confused.. why is having this conditional on TRACEPOINT_BENCHMARK a > > sane idea? > > Because the TRACEPOINT_BENCHMARK tests are insane, so a similar > level of insanity is required to make things work. Plus having this > be unconditional would not be good for performance, as 0day has been > telling me frequently over the past couple of years. > > All that aside, I am very open to ideas. What would you suggest?
Dunno; Steve how insane is that benchmark? Is it at all possible for an actual user to cause something like tha? Thing is, I find it very dodgy to have cond_resched() behaviour depend on a benchmark config. Either we should always have that (and somehow fix the performance issues) or we should not and then have the tracepoint crud not be insane, possibly adding a few of those cond_resched_trace_rcu_qs() things from the later patch.
