Messages in this thread | | | Date | Sun, 25 Feb 2018 21:47:27 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH tip/core/rcu 06/10] trace: Eliminate cond_resched_rcu_qs() in favor of cond_resched() |
| |
On Sun, Feb 25, 2018 at 11:57:48PM -0500, Steven Rostedt wrote: > On Sun, 25 Feb 2018 10:17:30 -0800 > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > > > > And probably not. You are probably running CONFIG_PREEMPT=y (otherwise > > RCU-tasks is trivial), so cond_resched() is a complete no-op: > > > > static inline int _cond_resched(void) { return 0; } > > > > I could make this call rcu_all_qs(), but I would not expect Peter Zijlstra > > to be at all happy with that sort of change. > > > > And the people who asked for the cond_resched() work probably aren't > > going to be happy with the resumed proliferation of cond_resched_rcu_qs(). > > > > Hmmm... Grasping at straws... Could we make cond_resched() be something > > like a tracepoint and instrument them with cond_resched_rcu_qs() if the > > current RCU-tasks grace period ran for more that (say) a minute of its > > ten-minute stall-warning span? > > > > Instead of monkeying with cond_resched(), since this is "special" code, > why don't I just have that code call it directly? > > cond_resched(); > rcu_note_voluntary_context_switch(current);
The advantage of the last patch that I sent is that the special call is in one place. (This is the one that adds the "special" definition for _cond_resched().)
Thanx, Paul
| |