This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FIFO DSRs... the 2nd


Hi Sergei,
[...]
Yes, you're right .... i overlooked this count. So it's correct to
clear the dsr_list pointers.

I'm glad we finally agree on that. I did try to program it as carefully as I can indeed. My initial goal for the optimization was to get rid of excessive ISR disable/enable invocation compared to the LIFO case, and then I realized that I can get rid of a few volatile fetches and the comparison inside the loop.

Still one thing. If a new dsr is enqueued while your process the
dsr's, the new dsr will not be processed. This may cause a longer irq
to dsr delay. Maybe a check for new dsrs should be made before leaving
the loop.

Well, I thought about it too and my feeling is that this won't noticeably decrease maximum ISR-to-DSR latency as IRQ could still occur just after you check again, only the probability is less. External code will check/invoke the DSRs pretty soon anyway. On the other hand, it adds yet another volatile variable fetch and subsequent check-and-branch to *every* invocation of the routine most of which will handle single DSR on a reasonably behaving system. Taking the above into account I can't actually decide what is better, so I left it to be as simple as possible for now. Somebody who is interested in actual profiling of this thing is free to check and change it later.

In fact one fundamental change w.r.t other algorithms is that the list
is not checked for emptiness on entry to the DSR invocation routine, but
the outside logic suggests it is never called with empty list, and the
assert that I've put at the beginning has never fired for me.

I only fear a dsr could not be runned until the next irq or scheduler lock happened. This would produce sometimes unpredictable delays. Maybe we could add a check for the dsr_list entry if a zero was read out of the next pointer of the irq. The irqs are locked at this time.


Overall, I'm highly confident the patch is OK, but as any change it
cries for as much testing as possible.

I'll start testing it next week.


Bye...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]