Re: Performance of spi_mpc83xx.c sucks.

["Joakim Tjernlund" <Joakim.Tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org>]

> -----Original Message-----
> From: David Brownell [mailto:david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org]
> Sent: den 2 december 2008 19:31
> To: Joakim Tjernlund
> Cc: 'Peter Korsgaard'; spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [spi-devel-general] Performance of spi_mpc83xx.c sucks.
> 
> 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 ...

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?

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

We a app that needs to 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.

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

I see, so leave thread alone :)

 Jocke


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