On Sat, Mar 28, 2020 at 10:06:35AM -0400, Joel Fernandes wrote: > On Thu, Mar 19, 2020 at 07:41:53PM -0700, Paul E. McKenney wrote: > > On Thu, Mar 19, 2020 at 08:48:38PM -0400, Steven Rostedt wrote: > > > On Thu, 19 Mar 2020 17:28:13 -0700 > > > "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote: > > > > > > > Good point. If interrupts are disabled, it will need to use some > > > > other mechanism. One approach is irqwork. Another is a timer. > > > > > > > > Suggestions? > > > > > > Ftrace and perf use irq_work, I would think that should work here too. > > > > Sounds good, will give it a go! And thank you for catching this! > > Since the the Tasks-RCU holdout thread is supposed to wake up periodically to > scan holdout tasks anyway, can it not detect the end of the Trace-RCU grace > period on its next wake up? Sorry if I missed something. It could, and that was how it was structured in the first version. The reason for the timed waits is to be able to print stall warnings. So here is the (abbreviated) sequence of events: o Callbacks appear, waking the kthread. o The kthread moves the callbacks to a private list and starts the grace period. o The kthread scans the tasklist, moving tasks that need further processing to the holdout list. Note that these tasks are holding out from being checked, not necessarily from being in a quiescent state. Note also that tasks that are checked and found to be in a read-side critical section are only added to the holdout list if their state cannot be modified. o The kthreads repeatedly scans the holdout list. Once a task has been successfully checked, it is removed from the holdout list. o When the holdout list is empty, the kthread stops scanning it. o However, the grace period is not necessarily over because some of the previously tasks might still be in their read-side critical sections. So, as noted above, the kthread does timed waits for the count of such tasks to go to zero, printing stall warnings along the way if it takes too long. Or am I missing your point? Thanx, Paul
