[ECOS] Re: DSR Scheduling Problem

[Sergei Organov <osv at javad dot 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?

No, it doesn't, but a new feature along with the choice is definitely
more cost than either one of those ;) Besides, I didn't want a new
feature, I wanted to see if the old one could be improved.

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

Sure, but the same is true for any other improvement. I suggested to
improve existing LIST scheduler, not to add yet another one.

> Keeping the old one, however, _is_ free.

I don't believe it is, provided a new one is added. Try to look at the
resulting code for DSRs management and I'm sure you'll see... It's
not free for those who needs to maintain the code and it's not free for
newcomers, IMHO. Being neither of those, I don't care that much though.

Besides, we have another problem with that. Consider the documentation
Stefan has been so kind to provide along with his nice patch:

+            ... Instead of LIST this
+            implementation processed the DSR and first come, first serve
+            order, which reduces the ISR to DSR delay."

Do you see the problem? Refer to documentation for LIST and notice that
it doesn't mention anything about the DSR processing order. As far as I
understand from earlier Nick's posts that was system decision not to
specify the order, and now we end up breaking those decision :(

To be consistent, one would need to change old option from
CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST to, say,
CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST_LIFO, call the new option
CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST_FIFO, and then try hard to explain
why in the hell both are there.

To summarize, it seems that instead of improving behavior by changing
minor implementation detail, we need to introduce two new options,
remove one old option, and simultaneously make implementation details
public. For me it doesn't seem reasonable from architectural point of
view, sorry. (Even though Nick just posted his agreement with your
arguments).

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

So the result in this given case is that the worst option is the default
one :( I don't in fact care much about theory, -- but the result does
matter, IMHO. Backward compatibility is very valuable goal, but keeping
it is not *always* the right choice, especially provided that an
application that could break relies on undocumented implementation
detail and thus is already somewhat broken. We just need to come to a
reasonable decision after weighting all pros and cons, -- that's why I
have posted this in the first place.

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

So are we going to give user a hint? I mean something along the lines:

"LIFO policy may introduce 2 times higher DSR latencies at some rare
conditions than FIFO and ARRAY, but it's there and is the default for
backward compatibility. Please consider to use either FIFO or ARRAY for
new projects."

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

Seems like putting on the user the responsibilities he can't cope with
:(

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

... with the worst real-time properties of all the available options :(

BTW, FIFO is fast and dirt-simple as well.

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

Strictly speaking, not to break working system means not to change
anything, that in turn means not to switch to a new eCos version.

> I don't care how much you want FIFO DSR scheduling -- you don't get to
> force it down my throat.

I'm happy I can't force it due to the nature of an open-source project.

[What in fact bothers me is why don't you care, -- do you in fact still
have feeling that LIFO could be better in some cases? I'd be thankful if
you share it with me if you have.]

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

Yes, indeed.

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

1. The resulting DSR scheduling option after the change is still exactly
   as documented.

2. The "tiny minority" (if any) are in fact those applications that will
   break, and they are already somewhat broken anyway (as they rely on
   undocumented implementation detail).

> I'm _not_ for allow them to force that change on everybody else.

I don't believe you really think that *every* change to eCos sources
should be put under yet another option as some "working" system
somewhere may break, right?

That's in fact was the aim of my post, -- to decide how to qualify this
particular change, as unconditional implementation improvement or
otherwise, and I still think it's the former though I'm willing to
change my opinion should somebody come up with a conflicting case.

Anyway, I have neither rights nor desire to force anything on anybody,
so please take all the above slightly easier.

Thanks for the valuable discussion.

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