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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core