On Tue, 25 Jul 2017 12:18:14 -0700 "Paul E. McKenney" <[email protected]> wrote:
> On Tue, Jul 25, 2017 at 02:12:20PM -0400, Steven Rostedt wrote: > > On Mon, 24 Jul 2017 14:44:31 -0700 > > "Paul E. McKenney" <[email protected]> wrote: > > > > > The handling of RCU's no-CBs CPUs has a maintenance headache, namely > > > that if call_rcu() is invoked with interrupts disabled, the rcuo kthread > > > wakeup must be defered to a point where we can be sure that scheduler > > > locks are not held. Of course, there are a lot of code paths leading > > > from an interrupts-disabled invocation of call_rcu(), and missing any > > > one of these can result in excessive callback-invocation latency, and > > > potentially even system hangs. > > > > What about using irq_work? That's what perf and ftrace use for such a > > case. > > I hadn't looked at irq_work before, thank you for the pointer! > > I nevertheless believe that timers work better in this particular case > because they can be cancelled (which appears to be the common case), they Is the common case here that it doesn't trigger? That is, the del_timer() will be called? > normally are not at all time-critical, and because running in softirq > is just fine -- no need to run out of the scheduling-clock interrupt. irq_work doesn't always use the scheduling clock. IIRC, it will simply trigger a interrupt (if the arch supports it), and the work will be done when interrupts are enabled (the interrupt that will do the work will trigger) > > Seem reasonable? Don't know. With irq_work, you just call it and forget about it. No need to mod or del timers. -- Steve
