Re: Performance of spi_mpc83xx.c sucks.

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

On Tuesday 02 December 2008, Joakim Tjernlund wrote:
> 
> >  Joakim> Won't polling for long periods starve user space? How to
> >  Joakim> overcome this?
> > 
> > I guess it won't be any worse than the processor being overloaded with
> > interrupts - In fact it's better, as there's more real work done.
> 
> It gets the work done faster but will starve everyone else in the process.
> The IRQ version doesn't do that.

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 ...


> >  Joakim> Why use a kernel thread(mpc83xx_spi.0) to do the work?  Would
> >  Joakim> it not be better if the polling was in process context?
> > 
> > I guess that's needed for the async stuff.
> 
> hmm, yes that sounds reasonable.

Doesn't sound so to me.  Recall that if you have four chipselects,
the driver using each chip can submit its own request ... *EVERY*
request made to the controller driver is async, entering a queue
and coming out when it's done.


> One could detect if the operation is 
> async or not and use process context if it is synchronous.

No you can't.

-------------------------------------------------------------------------
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=/