On Wed, Sep 04, 2019 at 10:19:19AM +0200, Peter Zijlstra wrote: > On Wed, Sep 04, 2019 at 12:00:39AM -0400, Joel Fernandes wrote: > > [ Resending since I messed up my last email's headers! ] > > > > On Tue, Sep 03, 2019 at 03:25:59PM +0200, Viktor Rosendahl wrote: > > > This patch implements the feature that the tracing_max_latency file, > > > e.g. /sys/kernel/debug/tracing/tracing_max_latency will receive > > > notifications through the fsnotify framework when a new latency is > > > available. > > > > > > One particularly interesting use of this facility is when enabling > > > threshold tracing, through /sys/kernel/debug/tracing/tracing_thresh, > > > together with the preempt/irqsoff tracers. This makes it possible to > > > implement a user space program that can, with equal probability, > > > obtain traces of latencies that occur immediately after each other in > > > spite of the fact that the preempt/irqsoff tracers operate in overwrite > > > mode. > > > > Adding Paul since RCU faces similar situations, i.e. raising softirq risks > > scheduler deadlock in rcu_read_unlock_special() -- but RCU's solution is to > > avoid raising the softirq and instead use irq_work. > > Which is right. Cool. > > I was wondering, if we can rename __raise_softirq_irqoff() to > > raise_softirq_irqoff_no_wake() and call that from places where there is risk > > of scheduler related deadlocks. Then I think this can be used from Viktor's > > code. Let us discuss - what would happen if the softirq is raised, but > > ksoftirqd is not awakened for this latency notification path? Is this really > > an issue considering the softirq will execute during the next interrupt exit? > > You'd get unbounded latency for processing the softirq and warnings on > going idle with softirqs pending. Thanks for sharing that. > I really don't see why we should/want to be using softirq here. Sure. makes sense. thanks, - Joel
