Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 7 Sep 2019 19:38:01 -0400
From:   Joel Fernandes <joel@joelfernandes.org>
To:     Viktor Rosendahl <viktor.rosendahl@gmail.com>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/4] ftrace: Implement fs notification for
 tracing_max_latency
Message-ID: <20190907233801.GA117656@google.com>
References: <20190905132548.5116-1-viktor.rosendahl@gmail.com>
 <20190905132548.5116-2-viktor.rosendahl@gmail.com>
 <20190906141740.GA250796@google.com>
 <c35722db-bb79-7e09-ac02-e82ab827e1e3@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c35722db-bb79-7e09-ac02-e82ab827e1e3@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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