Re: [ECOS] Re: DSR Scheduling Problem

[Nick Garnett <nickg@ecoscentric.com>]

Grant Edwards <grante@visi.com> writes:

> In gmane.os.ecos.general, you wrote:
> 
> >> Isn't ECOS about choice?
> 
> Yes.
> 
> > Well, unfortunately choice doesn't come for free.
> 
> And the new feature you want does?
> 
> > More testing, more opportunities for bugs, more confusion,
> > etc. I believe useless choices are evil.
> 
> Adding a new DSR scheduler doesn't come for free either.
> Keeping the old one, however, _is_ free.
> 
> >> Make this configurable option and allow users to try both. :-)
> >
> > Which of the options do you suggest to be the default?
> 
> The existing one, of course.  Always default to existing
> behavior when adding new options.
> 
> > How do you explain users the criteria to choose one algorithm
> > or another?
> 
> You don't.  Just explain the differences between the two
> algorithms.  It's up to the user to determine the criteria on
> which he's making his choice.
> 
> > How will user compare the choices in his tests when most of
> > time the algorithms behave exactly the same?
> 
> That's up to the user.
> 
> > How do you explain why LIFO choice is there in the first place
> > if it has no advantages?
> 
> It's already been explained:  LIFO is fast and dirt-simple.
> 
> > For example, the "array" choice for DSR queue does have an
> > excuse as being interrupts-disable-free, and it has an excuse
> > of not being the default as it has potential problems with
> > missing DSRs. What's an excuse for keeping LIFO choice?
> 
> The most important excuse is not changing things for people who
> have working systems.  I don't care how much you want FIFO DSR
> scheduling -- you don't get to force it down my throat.
> 
> > The only one I see is backward compatibility, but due to the
> > fact that eCos never specified exact order of DSRs it
> > shouldn't matter.
> 
> Lots of things that shouldn't matter do.  Don't arbitrarily
> force changes on everybody just to make a tiny minority happy.
> I'm all for allowing that minority to add another DSR
> scheduling option if they want.  I'm _not_ for allow them to
> force that change on everybody else.


I agree with everything that Grant says here.

Stefan's patch, give or take a bit of tidying and name changing, looks
just fine. Adding and removing DSRs remains deterministic, if not
quite constant-time, and resolves any reservations I might have about
adding FIFO queueing.

It should only go in as a configuration option and the original LIFO
mechanism should be the default. Most systems do not have interrupts
occuring at the sort of rate that would make DSR queueing order make
any difference. So we should default to the very simplest approach and
document the tradeoffs of each mechanism. Subsytems and drivers that
really want FIFO queueing can always have a "requires" statement in
their CDL for this option.


-- 
Nick Garnett                                          eCos Kernel Architect
http://www.ecoscentric.com                     The eCos and RedBoot experts
Besuchen Sie uns vom 14.-16.02.06 auf der Embedded World 2006, Stand 11-222
Visit us at Embedded World 2006, Nürnberg, Germany, 14-16 Feb, Stand 11-222


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