> -----Original Message-----
> From: David Brownell [mailto:[EMAIL PROTECTED]
> Sent: den 2 december 2008 21:46
> To: Joakim Tjernlund
> Cc: 'Peter Korsgaard'; [email protected]
> Subject: Re: [spi-devel-general] Performance of spi_mpc83xx.c sucks.
> 
> 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.

yeah, I know I need to investigate this further. I just want
to put the "starving" issue out of my mind. I feel a bit
uneasy about the busy wait nature of polling for potentially long
periods of time and that might slow down the rest of the system.

he, I just remembered that one of the complaints was that the SPI thread
started to consume a lot of CPU when it was polling :)

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

Here I was thinking LOWLAT as a per transaction flag that would mean that the 
driver
should try to complete the transactions as fast as possible. In my case that 
would mean
polling instead of IRQ driven.
I don't have a complete suggestion, just want to test the idea first.


-------------------------------------------------------------------------
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=/
_______________________________________________
spi-devel-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Reply via email to