Re: [PATCH 0/4] coresight: Add ETR-PERF polling.

From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Denis Nikitin <denik@google.com>
Cc: Leo Yan <leo.yan@linaro.org>, Mike Leach <mike.leach@linaro.org>,
	"coresight@lists.linaro.org" <coresight@lists.linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	 Daniel Kiss <Daniel.Kiss@arm.com>
Subject: Re: [PATCH 0/4] coresight: Add ETR-PERF polling.
Date: Wed, 5 May 2021 09:29:19 -0600	[thread overview]
Message-ID: <20210505152919.GA1766375@xps15> (raw)
In-Reply-To: <CAOYpmdGyq+GZYTZWXW-=0SBxRz=VeUwqR9n+1j0UjtjcnZrWaA@mail.gmail.com>

On Tue, May 04, 2021 at 11:46:20PM -0700, Denis Nikitin wrote:
> On Tue, Apr 27, 2021 at 9:04 AM Leo Yan <leo.yan@linaro.org> wrote:
> >
> > On Tue, Apr 27, 2021 at 09:47:46AM -0600, Mathieu Poirier wrote:
> >
> > [...]
> >
> > > > 2) ETR polling ensures that more trace is collected across the entire
> > > > trace session - seeking to reduce inconsistent capture volumes.
> > >
> > > I am not convinced disabling a sink to collect traces while an
> > > event is active is the right way to go.  To me it will add (more) complexity to
> > > the coresight subsystem for very little gains, if any.
> > >
> > > If I remember correctly Leo brought forward the exact same idea about a year ago
> > > and after discussion, we all agreed the benefit would not be important enough to
> > > offset the drawbacks.
> > >
> > > As usual I am open to discussion and my opinion is not set in stone.  But as I
> > > mentioned I worry the feature will increase complexity in the driver and
> > > produce dubious results.  And we also have to factor in usability which, as
> > > Al pointed, out will be a problem.
> >
> > Just want to remind one thing for ETR polling.  From one perspective,
> > the ETR polling mode is actually very similar with perf's snapshot
> > mode.  E.g. we can use specific interval to send USR2 singal to perf
> > tool to captcure CoreSight trace data, thus it also can record the
> > trace data continuously.
> >
> > I can see a benefit from ETR polling mode is it might introduce less
> > overhead than perf snapshot mode.  The kernel's mechanism (workqueue
> > or kernel thread) will be much efficiency than perf's signal handling
> > + SMP call with IPIs.
> >
> > So it's good to firstly understand if perf snapshot mode can meet the
> > requirement or not.
> 
> We evaluated the patch on Chrome OS and I can confirm that the quality
> of AutoFDO profiles greatly improved with the ETR polling.
> Tested with per-thread and system-wide mode.
> 
> Without ETR polling the size of the collected ETM data was very
> inconsistent on the same workload and could vary by a factor of two.
> This, in turn, affects the quality of the AutoFDO profiles generated from ETM.
> With ETR polling the data size became pretty stable.
> Performance evaluation shows a similar consistency in performance gain
> of AutoFDO optimization.
> This, I think, supports the idea that data collection right now is sensitive
> to the process scheduling and can be improved with ETR polling.
> 
> For the system-wide mode particularly we didn't see any other alternatives
> to collect data periodically on a long-running workload.
> We haven't tested snapshot mode though. The idea sounds interesting.
> But small runtime overhead is crucial for the sampling profiler in the field
> and if there is a noticeable difference we would incline towards the
> ETR polling.

Please see if Leo's approach[1], or any kind of extension to the current
snapshot feature, would be a viable solution.  Reusing or extending code that is
already there is always a better option.

Thanks,
Mathieu

[1]. https://lists.linaro.org/pipermail/coresight/2021-April/006254.html

> 
> Thanks,
> Denis
> 
> >
> > Thanks,
> > Leo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel