Re: [ECOS] Re: DSR Scheduling Problem

[Nick Garnett <nickg at ecoscentric dot com>]

Jay Foster <jay@systech.com> writes:

> I still think that FIFO queuing of the DSRs is better than LIFO queuing,
> because in the absence of any DSR priority information, the best that can be
> done is temporal priority (ie FIFO).  This prevents the case (that I'm
> seeing) where a lower priority ISR's DSR preempts a higher priority ISR's
> DSR (the priority is lost in the LIFO DSR queue).

I think the main thing to try and discover is why your application is
so sensitive to the mere order in which DSRs are called. What
relationship exists between these DSRs that causes a problem when they
are called in a particular order? What might your main program be
doing to delay or otherwise interfere with DSR calling?

In general DSRs are independent of each other, the order in which two
or more pending DSRs get called should not matter. In any event they
all get called before any threads get to run, so the order does not
propogate to the threads, which will be run in priority order.

> 
> I located the kernel versions of the DSR code
> (kernel/current/src/intr/intr.cxx), and discovered that there are two
> implementations for the DSR handling (CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST,
> and CYGIMP_KERNEL_INTERRUPTS_DSRS_TABLE).  The default is to use the LIST,
> which is LIFO, but the TABLE implementation is FIFO.  I switched my
> configuration to the TABLE implementation, and my code works.  So a second
> reason to use FIFO for the DSR LIST implementation is to match the behavior
> of the TABLE implementation.

I suspect that changing from LIFO to FIFO order is actually just
masking some other underlying problem. For example that the CPU is
just not up to the job of handling the load being asked of it. For
there to be more than one DSR pending more than very occasionally you
would have to have a very high interrupt rate, virtually saturating
the CPU. Your figure of a 39ms delay before the DSR runs is very
suggestive of something like this. It looks like your transmitter is
simply saturating the CPU.

The LIFO queueing method was chosen because it is fast, deterministic
and simple to maintain. I would be very reluctant to see a change to
this unless a *very* good case is made for FIFO order.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss