On Sat, Sep 07, 2019 at 11:12:59PM +0200, Viktor Rosendahl wrote: > On 9/6/19 4:17 PM, Joel Fernandes wrote: > > On Thu, Sep 05, 2019 at 03:25:45PM +0200, Viktor Rosendahl wrote: > <clip> > > > + > > > +__init static int latency_fsnotify_init(void) > > > +{ > > > + fsnotify_wq = alloc_workqueue("tr_max_lat_wq", > > > + WQ_UNBOUND | WQ_HIGHPRI, 0); > > > + if (!fsnotify_wq) { > > > + pr_err("Unable to allocate tr_max_lat_wq\n"); > > > + return -ENOMEM; > > > + } > > > > Why not just use the system workqueue instead of adding another workqueue? > > > > For the the latency-collector to work properly in the worst case, when a > new latency occurs immediately, the fsnotify must be received in less > time than what the threshold is set to. If we always are slower we will > always lose certain latencies. > > My intention was to minimize latency in some important cases, so that > user space receives the notification sooner rather than later. > > There doesn't seem to be any system workqueue with WQ_UNBOUND and > WQ_HIGHPRI. 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.
Ok, a separate WQ is fine with me as such since the preempt/irq events are on a debug kernel anyway. I'll keep reviewing your patches next few days, I am at the LPC conference so might be a bit slow. Overall I think the series look like its maturing and getting close. thanks, - Joel