Messages in this thread | | | Date | Mon, 23 Apr 2018 16:03:42 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH tip/core/rcu 01/22] sched: Make non-production PREEMPT cond_resched() help Tasks RCU |
| |
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.
| |