Performance of spi_mpc83xx.c sucks.

Performance of spi_mpc83xx.c sucks.

[Joakim Tjernlund]

We have noticed that the spi_mpc83xx.c driver is very slow, the gap
between words are huge.
So I started to optimise it and it still sucks.
However, if I poll the SPIE_NF SPIE_NE bits instead it works MUCH
better, like so:
		struct mpc83xx_spi_reg *regs = mpc83xx_spi->base;
		u32 event=SPIE_NF;

		mpc83xx_spi->tx_count -= 1;
		word = mpc83xx_spi->get_tx(mpc83xx_spi);
		mpc83xx_spi_write_reg(&regs->transmit, word);
		if (len >= 2) { /* FIFO is 2 words */
			mpc83xx_spi->tx_count -= 1;
			word = mpc83xx_spi->get_tx(mpc83xx_spi);
			mpc83xx_spi_write_reg(&regs->transmit, word);
		}
		clear_need_resched();
		do {
			if (event & SPIE_NE) {
				word = mpc83xx_spi_read_reg(&regs->receive);
				mpc83xx_spi->rx_count -= 1;
				if (mpc83xx_spi->rx)
					mpc83xx_spi->get_rx(word, mpc83xx_spi);

				if ((event & SPIE_NF) && mpc83xx_spi->tx_count) {
					mpc83xx_spi->tx_count -= 1;
					word = mpc83xx_spi->get_tx(mpc83xx_spi);
					mpc83xx_spi_write_reg(&regs->transmit, word);
				}

			} else if (need_resched()){
				clear_need_resched();
				schedule();
				printk("Cond, rx:%d\n", mpc83xx_spi->rx_count);
			}

			event = mpc83xx_spi_read_reg(&regs->event);
			} while (mpc83xx_spi->rx_count);

I am not sure what this polling will do to the system though. Is this really bad to do?
The resched() stuff doesn't seem to work, probably becase I don't know how
to use it properly :(

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

Re: Performance of spi_mpc83xx.c sucks.

[Peter Korsgaard]

>>>>> "Joakim" == Joakim Tjernlund <joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org> writes:

 Joakim> We have noticed that the spi_mpc83xx.c driver is very slow, the gap
 Joakim> between words are huge.
 Joakim> So I started to optimise it and it still sucks.
 Joakim> However, if I poll the SPIE_NF SPIE_NE bits instead it works MUCH
 Joakim> better, like so:

Yes, I've noticed the same. I get around ~5 times higher throughput
with a simple polled loop in U-Boot compared to under Linux (66MHz
clock).

I've written it of as simply being a question of interrupt overhead
(at 66MHz / 32bits we're talking over 2 million interrupts per
second - E.G. only ~100 instructions between each!)

Maybe it indeed makes more sense to use polling for high bitrates.

-- 
Bye, Peter Korsgaard

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

Re: Performance of spi_mpc83xx.c sucks.

[Joakim Tjernlund]

> -----Original Message-----
> From: Peter Korsgaard [mailto:jacmet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] On Behalf Of Peter Korsgaard
> Sent: den 21 oktober 2008 20:14
> To: Joakim Tjernlund
> Cc: spi-devel-general
> Subject: Re: [spi-devel-general] Performance of spi_mpc83xx.c sucks.
> 
> >>>>> "Joakim" == Joakim Tjernlund <joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org> writes:
> 
>  Joakim> We have noticed that the spi_mpc83xx.c driver is very slow, the gap
>  Joakim> between words are huge.
>  Joakim> So I started to optimise it and it still sucks.
>  Joakim> However, if I poll the SPIE_NF SPIE_NE bits instead it works MUCH
>  Joakim> better, like so:
> 
> Yes, I've noticed the same. I get around ~5 times higher throughput
> with a simple polled loop in U-Boot compared to under Linux (66MHz
> clock).
> 
> I've written it of as simply being a question of interrupt overhead
> (at 66MHz / 32bits we're talking over 2 million interrupts per
> second - E.G. only ~100 instructions between each!)
> 
> Maybe it indeed makes more sense to use polling for high bitrates.

The cpu can't keep up at ~10MHz for me, but even at much small Hz
the poll is significantly faster, the IRQ overhead seems huge or is it 
something else?
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?

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

Re: Performance of spi_mpc83xx.c sucks.

[David Brownell]

On Tuesday 21 October 2008, Joakim Tjernlund wrote:
> 
> > Maybe it indeed makes more sense to use polling for high bitrates.
> 
> The cpu can't keep up at ~10MHz for me, but even at much small Hz
> the poll is significantly faster, the IRQ overhead seems huge or is it 
> something else?

I'd guess IRQ-per-word is a bad design policy ... If you assume 10 MHz
SPI clock, and (keeping math simple) a 10-bit word, then a polling loop
of 1 MHz -- 1 usec/loop -- is needed to keep up.

Regardless of latency, per-IRQ overheads (save context, call handler,
do its work, return, restore) are not always below 1 usec...


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

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

Re: Performance of spi_mpc83xx.c sucks.

[Joakim Tjernlund]

On Thu, 2008-11-20 at 20:10 -0800, David Brownell wrote:
> On Tuesday 21 October 2008, Joakim Tjernlund wrote:
> > 
> > > Maybe it indeed makes more sense to use polling for high bitrates.
> > 
> > The cpu can't keep up at ~10MHz for me, but even at much small Hz
> > the poll is significantly faster, the IRQ overhead seems huge or is it 
> > something else?
> 
> I'd guess IRQ-per-word is a bad design policy ... If you assume 10 MHz
> SPI clock, and (keeping math simple) a 10-bit word, then a polling loop
> of 1 MHz -- 1 usec/loop -- is needed to keep up.
> 
> Regardless of latency, per-IRQ overheads (save context, call handler,
> do its work, return, restore) are not always below 1 usec...
> 
> 
> > 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? 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?

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

Re: Performance of spi_mpc83xx.c sucks.

[Peter Korsgaard]

>>>>> "Joakim" == Joakim Tjernlund <joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org> writes:

Hi,

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

 Joakim> Sorry for the delay, forgot about this.

 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.

 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.

-- 
Bye, Peter Korsgaard

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

Re: Performance of spi_mpc83xx.c sucks.

[Joakim Tjernlund]

> -----Original Message-----
> From: Peter Korsgaard [mailto:jacmet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] On Behalf Of Peter Korsgaard
> Sent: den 2 december 2008 17:24
> To: joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org
> Cc: David Brownell; spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [spi-devel-general] Performance of spi_mpc83xx.c sucks.
> 
> >>>>> "Joakim" == Joakim Tjernlund <joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org> writes:
> 
> Hi,
> 
>  >> 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.
> 
>  Joakim> Sorry for the delay, forgot about this.
> 
>  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.

> 
>  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. One could detect if the operation is
async or not and use process context if it is synchronous.

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

Re: Performance of spi_mpc83xx.c sucks.

[David Brownell]

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

Re: Performance of spi_mpc83xx.c sucks.

[Joakim Tjernlund]

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

Re: Performance of spi_mpc83xx.c sucks.

[David Brownell]

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

Re: Performance of spi_mpc83xx.c sucks.

[Joakim Tjernlund]

> -----Original Message-----
> From: David Brownell [mailto:david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org]
> Sent: den 2 december 2008 21:46
> 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:
> > >
> > > 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=/

Re: Performance of spi_mpc83xx.c sucks.

[David Brownell]

On Tuesday 02 December 2008, Joakim Tjernlund wrote:
> 
> > 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.

You won't be able to do that without solid data.  You're
still just speculating.


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

Yet $SUBJECT is about suckage with IRQ-driven transfers, slowing
down the system.  There is a common thread ...

A first-principles analysis would help.  What SPI clock rate is
involved, and how big are the data transfers?  It should be easy
to come up with a per-word instruction count ceiling for polling,
and compare that to the IRQ overhead.

Then remember that unless you've got DMA, you're stuck with some
CPU costs here.  So the question is only how/when you incur them:
in bursts giving adequate SPI throughput, or spread out over time
giving objectionably low throughput?


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

Re: Performance of spi_mpc83xx.c sucks.

[David Brownell]

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

Re: Performance of spi_mpc83xx.c sucks.

[Joakim Tjernlund]

> -----Original Message-----
> From: David Brownell [mailto:david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org]
> Sent: den 2 december 2008 19:17
> To: joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org
> 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:
> > > > 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 ... :)

:), I wish I had the time to do such a driver.

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

Oh, so the kernel thread actually gets pre-empted(is that a word?)
once it has consumed its "time slice"? Do I need to turn on
pre-empt support in the kernel for this?

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

Re: Performance of spi_mpc83xx.c sucks.

[David Brownell]

On Tuesday 02 December 2008, Joakim Tjernlund wrote:
> Oh, so the kernel thread actually gets pre-empted(is that a word?)
> once it has consumed its "time slice"?

And potentially at other times.  When an IRQ arrives and
is handled, that's a form of non-task preemption.  And
when that IRQ enables a higher-priority task, the lower
priority one can be preempted in a more usual manner.


> Do I need to turn on 
> pre-empt support in the kernel for this?

To get some kinds of preemption, yes.  But it's not
strictly required.

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