Re: Performance of spi_mpc83xx.c sucks.

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

On Tuesday 02 December 2008, Joakim Tjernlund wrote:
> > 
> > I've not observed polling from a task context to starve anyone,
> > when done sanely.  The opposite is true for doing an order of
> > magnitude more instructions in IRQ context ...
> 
> When playing with this the app developer complained that the system didn't
> behave as expected so I guessed it had to do with starvation. Perhaps
> lowering the prio or something would be a wise thing to do? Or is the thread
> already at lower prio than normal userspace processes?

If you're only guessing about what's going on, you need to go
back and get solid data.  What does "as expected" mean?  Some
app developers have silly expectations.  If you were "playing"
the issue could more easily have been goofs in your code.


> I guess you are not keen on a LOWLAT option for SPI transfers?

Again, you're guessing in absence of facts ... including a
concrete proposal for what a "LOWLAT option" would be here,
and how it would relate to that one developer's possibly
unrealistic expectations in the context of a collection of
experimental kernel hacks vs. using a saner implementation
of the I/O loops to start with.

 
> We a app that needs to do protection

What is "do protection"?


> (in its own RT pthread) so any SPI 
> transfers should be performed as quickly as possible when the protection
> thread is running, for the rest speed it doesn't matter.

You're free to impose whatever queuing discipline you like
so long as it's FIFO as observed by each spi_device driver.

I would not advise trying to have spi_master.transfer()
methods infer anything about the call context, though.
Such methods are fragile, and are frowned upon in Linux.

- Dave

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/