On 18/10/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> (1) time spent in ISR;
> (2) some prologue for the very first shared handler and epilogue - for the
> last one.

(2) is the rare case that multiple IRQs happen at the same time on the
same line. As I said, the case when only one occurs and the others are
needlessly tested is more often.

Indeed, it looks like "prologue" and "epilogue" are always accounted to the ISR that reported XN_ISR_HANDLES. And if it's only one, then its position in the chain doesn't matter.

> The "simple" model accounts only (1) to ISR time statistics so it's always
> easy to say what's this number means. It just describes the load caused
> by a
> corresponding ISR handler.

[sorry, Dmitry, for this replay ;)]

I somehow read it as "sorry for this _reply_" and thought you had expressed below all you think about my complains and myself... but, ok. you are more polit-correct :)))

I designed this instrumentation with a fairly old question of mine in
the head: "What does raising this IRQ, say, at 1 KHz costs the system?"
And this question includes not just the ISR itself, but also the
disturbance due to potential rescheduling.


Shared Interrupt are indeed an exception, and if we were only discussing
non-shared instrumentation here, I guess it wouldn't be that tricky to
find a common model. If you look at that part, I'm basically shifting
some instrumentation point after the rescheduling, that's it.

yes, per-IRQ accounting (as opposed to per-ISR) wouldn't have a background for such objections.

Well, if we conclude that the enhanced scheme provides better informativeness and everyone benefiits from it, then let it be so. I don't have any more objections [chores : uufff, haleluia!]


Best regards,
Dmitry Adamushko

Xenomai-core mailing list

Reply via email to