Re: [Xenomai-core] [PATCH 0/3] Reworked nucleus statistics

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3379 bytes --]

Dmitry Adamushko wrote:
>> ...
>>
>> Dmitry, are there other issues I'm missing, that you think would be
>> better solved using a simpler accounting model?
> 
> 
> So according to you, the more complex model gives users a better
> understanding of behavior of their drivers/applications?
> 
> ...
>>   0  0      0          201357   0     00000000      2.8  IRQ1: handler1
>>   0  0      0          5811       0     00000000      2.4  IRQ1: handler2
> 
> what is % in this case?
> 
> it accounts :
> 
> (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.

> 
> So in fact, part (1) can be the same for both handlers (say, just the same
> code), N can be == M (irq frequency) but % numbers are different. Is it
> fair?
> 
> 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 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.

> 
> Ok, if somebody wants to tell me that shared interrupts is an exceptional
> and rare case, then I got it. But anyway, as long as we want to provide
> per-ISR (and not per-IRQ) statistics, it adds some unclearness (unfairness)
> on how to consider reported values.

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.

> 
> I also expected that those prologue and epilogue are likely to cause much
> lighter "disturbance" being added to a preempted thread (because such
> threads normally should have higher % load wrt ISR anyway).
> 
> Regarding accounting only XN_ISR_HANDLED cases. At least, I suppose,
> ISR[n+1] doesn't get accounted the interval of time spent by ISR[n] to
> report XN_ISR_NONE?
> 
> Which brings us to the next point that I didn't get it from the 3-d patch
> after looking at it brielfy (well, I didn't apply it yet).
> And in general, it's getting a bit more difficult to see interrupt handling
> details behind statistic-handling ones, esp. in the case of shared
> interrupts. Of course, that's really a minor issue as long as users may get
> better statistic information :)
> 
> ok, that was kind of a summary, I hope I didn't forget anything else as we
> already had quite a long discussion with Jan.
> 
> all in all (yep, I like repeating myself :) IMHO the simple model, at
> least,
> clearly answeres a question what's behind the numbers while the complex one
> makes the answer more complex trying to be fair in one place and at the
> same
> time adding "unfairness" in another place.
> 

I don't see that the remaining unfair parts are significant - at least
/wrt what I want to analyse here.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]