From: Philippe E. <ph...@cl...> - 2002-01-01 23:10:26
|
> > > I agree the needs to better document oprofile but in your examples > > I don't think than seeing a ratio different to the expected ratio is due > > to irq latency. The latency is the same for sample which belongs to > > fun1 or fun2. I means than the probability to get samples to fun1 which > > would credited to fun2 and the reverse case are identical > > jeff actually saw this problem. He was using two similar counters on a Duron, > and they contradicated each other. Added other code inbetween fixed it. > > This was current CVS. > > If a lot of samples happen to be causing the overflow at the end of one function > but not the other, then we can easily see samples for the one ending up in the > other, and vice versa. > > for any particular sample, it can easily end up in the "next" function as we > count it. The effect is ameliorated for larger functions... that's the effect of NMI occur due to counter1, counter 1 is treated and during the same NMI counter 2 overflow. I have see than intel VTUNE apparently use only one counter during profiling. Perhaps we need to document than separate runs on the same set of data give better result. We can perhaps also provide an option "increase reliablilty" and inhibit counter during NMI treatment ? Having different NMI handler is perhaps a good solution. I means just the NMI handler itself at assembly level. oprofile_nmi.s do_nmi_precise() { disable count() call op_do_nmi enable_count(); } do_nmi() { call op_do_nmi } this reduce greatly the windows of possible overflow. > > P.S.: john your email address was broken, you have perhaps missed some mail > > yes, I dropped about a day or two's email. Did I miss anything oprofile related ? Have you see, my request: "can you write the SIGUSR1 thing" ? That the last need before starting test... The remaining update would be only doc improvement. regards, Phil |