Re: spi_async and heavy CPU occupation by ksoftirqd

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

On Thursday 09 August 2007, llandre wrote:
> > At a first glance, I wonder if you're not spending too much time
> > in the spi_imx "pump_transfers" tasklet.  I have no idea how well
> > tuned that driver is...
> 
> Hmmm ... how do you suggest me to investigate around this tasklet? Do I 
> need to use the toggling pin technique

That seems to be the most precise tool you have, unless you
have access to the JTAG-style hardware tools giving access
to the on-chip instruction trace buffers found in many ARMs.


> or does the kernel provides some  
> tools to do that? Could oprofile come to help?

Statistical profiling probably wouldn't help.  I'm not sure that
anything like gprof is working in the kernel.  Folk that I know
have done that level analysis tend to rely on hardware trace tools.


> > I'd expect that using spi_sync() wouldn't save much, but it might
> > be worth verifying that.
>
> Initially my driver used spi_sync. When I realized the huge CPU 
> occupation I modified it in order to use spi_async instead but, again, 
> nothing changed.

And that should have been a HUGE clue that the way you were calling
it wasn't a factor at all.  

- Dave

 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/