[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180225235748.4ce882e5@vmware.local.home>
Date: Sun, 25 Feb 2018 23:57:48 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org,
jiangshanlai@...il.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, tglx@...utronix.de, peterz@...radead.org,
dhowells@...hat.com, edumazet@...gle.com, fweisbec@...il.com,
oleg@...hat.com, Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH tip/core/rcu 06/10] trace: Eliminate
cond_resched_rcu_qs() in favor of cond_resched()
On Sun, 25 Feb 2018 10:17:30 -0800
"Paul E. McKenney" <paulmck@...ux.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);
-- Steve
Powered by blists - more mailing lists