On Fri, 20 Sep 2019 17:22:16 +0200 "Viktor Rosendahl (BMW)" <[email protected]> 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. > > This facility works with the hwlat, preempt/irqsoff, and wakeup > tracers. > > The tracers may call the latency_fsnotify() from places such as > __schedule() or do_idle(); this makes it impossible to call > queue_work() directly without risking a deadlock. The same would > happen with a softirq, kernel thread or tasklet. For this reason we > use the irq_work mechanism to call queue_work(). Can fsnotify() be called from irq context? If so, why have the work queue at all? Just do the work from the irq_work handler. -- Steve > > This patch creates a new workqueue. The reason for doing this is that > I wanted to use the WQ_UNBOUND and WQ_HIGHPRI flags. My thinking was > that WQ_UNBOUND might help with the latency in some important cases. > > If we use: > > queue_work(system_highpri_wq, &tr->fsnotify_work); > > then the work will (almost) always execute on the same CPU but if we are > unlucky that CPU could be too busy while there could be another CPU in > the system that would be able to process the work soon enough. > > queue_work_on() could be used to queue the work on another CPU but it > seems difficult to select the right CPU. >
