Re: [PATCH v6 1/4] ftrace: Implement fs notification for tracing_max_latency

[Joel Fernandes <joel@joelfernandes.org>]

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