Messages in this thread | | | Subject | Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state | From | Byungchul Park <> | Date | Mon, 14 May 2018 12:11:59 +0900 |
| |
On 2018-05-13 오전 2:26, Steven Rostedt wrote: > On Sat, 12 May 2018 07:41:19 -0700 > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > >> Don't get me wrong, this discussion was quite useful to me. We probably >> need to at least change the comments, and perhaps the code as well. But >> I agree that we need input from Peter and Steven to make much more forward >> progress. > > It's the weekend so I skimmed more than read this thread, but I will > just add this. > > The table Joel posted is interesting, and perhaps we should keep things > consistent with that. But that said, with respect to task-RCU, as > nothing on a trampoline should ever call cond_resched() (and perhaps I > should add code in lockdep that verifies this), we just want a > quiescent state that tells us that the task has left the trampoline. A > cond_resched() should be one of those points that does. > > It really has nothing to do with scheduling or preemption. The issue is > that if a task is on a trampoline and gets preempted, there's no > knowing when it is off that trampoline where we can free it. We need to > have places in the kernel that we know is a quiescent state to move > task-RCU forward. cond_resched() seems to be one of them. schedule > itself can not be, because it can be called from an interrupt preempting > a task while it is on the trampoline.
Exactly. I think Steven explained how we should consider them exactly.
> -- Steve -- Thanks, Byungchul
| |