Re: Performance of spi_mpc83xx.c sucks.

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

On Tuesday 02 December 2008, Joakim Tjernlund wrote:
> > > The question is if the poll code I sent is good, even for longer transfers?
> > > Perhaps some sort of LOWLAT flag could be used for transfers that really need them?
> > 
> > So long as you do the polling with IRQs enabled, I'd keep it simple and
> > just always poll.  YMMV of course, but most devices seem to prefer more
> > like 10 MHz clocks than 1 MHz ones.
> 
> Sorry for the delay, forgot about this.
> 
> Won't polling for long periods starve user space?

If your system is that I/O bound, use DMA ... :)

> How to overcome this? 
> Why use a kernel thread(mpc83xx_spi.0) to do the work?
> Would it not be better if the polling was in process context?

Using a kernel thread, like the not-so-well-named bitbang
utilities will do for you, *does* ensure the polling is
done in a process context.  If it's interruptible, as I
suggested, it should also be pre-emptible ... so if its
activity (polling) gets to be serious overhead, some other
task can be scheduled.



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