public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Sergei Organov <osv@javad.com>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS]  Re: DSR Scheduling Problem
Date: Mon, 13 Feb 2006 10:41:00 -0000	[thread overview]
Message-ID: <dspnop$dis$1@sea.gmane.org> (raw)
In-Reply-To: <dq9mma$d9l$1@sea.gmane.org>

> On 2006-01-14, Jay Foster <jay@systech.com> wrote:
>> 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).

Nick Garnett <nickg@ecoscentric.com> writes:
> 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.

Grant Edwards <grante@visi.com> writes:
> That happens to work for your application, but I don't see how
> you can say that FIFO is best in the general case.

That brought an interesting question, so I've tried to figure out some
numbers. I took IRQ-to-corresponding-DSR latency as the comparison
criteria, and my analysis of rather simple system suggests that LIFO
could be 2 times worse than FIFO at some conditions and is never
better. Though I've tried my best to make the comparison fair, I must
admit that I'm somewhat biased in favor of FIFO (LIFO wait queues just
sound wrong in the first place), and I'd be thankful should somebody
find a mistake in my reasonings below.

For the purpose of comparison I considered rather simple yet usual
system with the following properties:

1. There are N independent asynchronous interrupt sources
   IRQ1-IRQN. IRQ1 has highest priority and IRQN has lowest priority.

2. System load is low and each of interrupts happens so rarely that an
   IRQ never occurs when ISR/DSR corresponding to previous IRQ of this
   particular kind is active.

3. ISRs don't nest.

4. Difference between FIFO and LIFO management overheads is negligible
   compared to ISR + DSR execution times.

Now let's try to calculate *maximum* IRQ-to-DSR latency for IRQ1 that
has the highest priority. For simplicity let's assume every ISR handler
takes roughly the same time Ti for execution and every DSR handler takes
roughly the same time Td.

First consider FIFO case.

If Td => Ti, maximum latency is reached, e.g., when all the IRQs but
IRQ1 happen almost simultaneously, then IRQ1 happens just before the
beginning of DSR2 execution:
             IRQ1 
              v
ISR2,...,ISRN, ISR1,DSR2,...,DSRN,DSR1

and maximum IRQ1-to-DSR1 latency LF1 = Ti + Td * (N - 1)

If Ti >= Td, maximum latency is reached when, say, IRQ2 happens, ISR2
begins to execute, then IRQ1,IRQ3,...,IRQN happen almost immediately (in
whatever order). In this case the order of execution is:

IRQ1
v   
ISR2,ISR1,ISR3,...,ISRN,DSR2,DSR1,...,DSRN,

and LF2 = Ti * (N - 1) + Td

Overall, maximum IRQ1-to-DSR1 latency for FIFO policy is:

        | Td * (N - 1) + Ti, Ti <= Td 
LFmax = |
        | Ti * (N - 1) + Td, Ti >= Td


Now consider LIFO case.

The worst case w.r.t. DSR1 latency is:

IRQ1
v   
 ISR1,ISR2,....,ISRN,DSRN,...,DSR2,DSR1

and LL2 = Ti * N + Td * (N - 1)

and maximum IRQ1-to-DSR1 latency for LIFO policy is:

LLmax = Ti * N + Td * (N - 1)


Please note that:

1. LLmax >= LFmax

2. If Ti = Td,  LLmax/LFmax = 2 - 1/N,

   So, maximum DSR latency for the highest priority IRQ could be nearly
   2(!) times more for LIFO policy than for FIFO one.

3. Minimum latencies are the same and are equal to Ti (FIFO vs. LIFO
   overhead aside).

3. Mean latencies are almost the same for LIFO and FIFO policies for our
   system where interrupts occur so rarely that most probable case is
   single ISR followed by corresponding DSR (Lmean~=Ti).


Overall, the above analysis suggests LIFO is never better than FIFO and
it could be much worse than FIFO.

Isn't it time to finally get rid of LIFO wait queues in eCos? Any
objections?

-- Sergei.


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

  parent reply	other threads:[~2006-02-13 10:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-14  0:45 Jay Foster
2006-01-14  2:12 ` Grant Edwards
2006-01-14  3:04   ` Paul D. DeRocco
2006-01-14  3:40     ` Grant Edwards
2006-01-16  8:40       ` Daniel Néri
2006-01-16 10:36         ` Nick Garnett
2006-01-16 11:45           ` [ECOS] Generic 16x5x serial driver use of transmit FIFO (was: DSR Scheduling Problem) Daniel Néri
2006-01-16 12:23             ` Nick Garnett
2006-01-16 15:13         ` [ECOS] Re: DSR Scheduling Problem Grant Edwards
2006-01-17  9:43         ` Andrew Lunn
2006-01-16  8:27   ` Dirk Husemann
2006-01-16 15:11     ` Grant Edwards
2006-02-13 10:41   ` Sergei Organov [this message]
2006-02-15  2:06     ` Brett Delmage
2006-02-15  9:57       ` Sergei Organov
2006-02-15 13:23         ` Stefan Sommerfeld
2006-02-15 14:07           ` Sergei Organov
2006-02-15 14:14             ` Stefan Sommerfeld
2006-02-15 15:54           ` Grant Edwards
2006-02-15 15:53         ` Grant Edwards
2006-02-15 18:30           ` Nick Garnett
2006-02-15 19:30             ` Sergei Organov
2006-02-16 10:00               ` Nick Garnett
2006-02-16 13:09                 ` Sergei Organov
2006-02-15 19:36           ` Sergei Organov
2006-02-15 19:57             ` Grant Edwards
2006-02-16 14:08               ` Sergei Organov
2006-02-15 16:34         ` Brett Delmage
2006-01-14  8:23 ` Andrew Lunn
2006-01-16 10:27 ` Nick Garnett
  -- strict thread matches above, loose matches on Subject: below --
2006-02-13 14:51 Uwe Kindler
2006-02-13 15:26 ` Grant Edwards
2006-01-13 23:01 [ECOS] " Jay Foster
2006-01-13 23:38 ` [ECOS] " Grant Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='dspnop$dis$1@sea.gmane.org' \
    --to=osv@javad.com \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).