Re: [PATCH 2/2] spi: add statistics gathering and reporting methods

[Jakub Kiciński <moorray3@xxxxx>]

On Tue, 5 May 2015 16:02:46 +0100, Mark Brown wrote:
> On Tue, May 05, 2015 at 02:20:08PM +0200, Jakub Kiciński wrote:
> > On Mon, 4 May 2015 16:25:01 +0200, Martin Sperl wrote:
> 
> > > that makes it much more complicated to add things per spi_master
> > > implementation (which was my original idea: have a framework that exposes
> > > the distinct transfer modes of the spi-bcm2835 driver (polling, interrupt
> > > and dma driven) and also to get some stats on how often we run into those
> > > “corner” cases - that is also why I want to gather the histogram
> > > statistics, as it may make it easier to understand the use cases of people
> > > who complain about “performance” in case they share those infos…
> 
> > You can also consider adding few strategically placed tracepoints.  
> > It saves the amount of kernel code necessary and is generally more
> > flexible.
> 
> We already have a bunch of tracepoints in there (probably sufficiently
> detailed for what's here) but they solve a different problem to
> statistics - while you can extract statistics at least as far back as
> the tracepoints go but it's slightly cumbersome and for longer term
> tests the buffer will roll round at some point and it's a bit more work
> for people to set them up.

Sure, I definitely agree with complicated setup especially that Martin
is targeting this at RPi users who are usually not the most seasoned
of kernel developers.  Perhaps one day someone will write a generic
tracepoint-like statistic subsystem which can be disabled at runtime
and easily compiled-out...
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html