From: Don Z. <dz...@gm...> - 2006-04-04 16:14:14
|
On 4/4/06, Stephane Eranian <er...@hp...> wrote: > Don, > > On Mon, Apr 03, 2006 at 04:32:46PM -0500, Don Zickus wrote: > > > > I was trying to fix some functionality in the nmi watchdog but > > unfortunately it broke how oprofile works. As a result I was trying > > to come up with a patch that would fix the oprofile issue. The > > problem revolves around the fact that oprofile uses the same > > performance counter register as the nmi watchdog. Thus if one were to > > start oprofile, they would accidentally disable the watchdog, which in > > turn would cause other nmi watchdog issues. > > > I welcome your initiative. I have had problems dealing with this NMI > code with the perfmon2 subsystem. > > I looked at the patch and I am not quite sure what the goal is > with the reserve_perftctr_nmi()/release_perfctr_nmi(). The logic > seems to be that Oprofile or perfmon2 would share the counters > with the NMI watchdog. If NMI watchdog is active, then they > have one less counter (a counter group for P4). I am sure this > could break some tools because most of the time they are not prepared > to deal with unavailable counter. You need to convery that the counter > is unavailable as opposed to implemented so that they can try requesting > the same set of events BUT with another event -> counter assignement. Thanks for the feedback (both Stephane and Andi). I didn't realize my patch would break the user space API. :( Initially I was trying to figure out a way to make that counter unavailable but couldn't find the right piece of code, so I went the other way and denying a request. If you could point me to the code which shows user space which counters are available, I would happily re-work the patch. > > The reservation works if you assume that NMI watchdog and Oprofile NMI-ba= sed > interruption can work together. I do not see where you can chain the inte= rrupt > handler on NMI interrupt. The set_nmi_callback() replaces the existing ha= ndler, > it does not add a new one. Thus, you break one or the other. If you canno= t > chain the NMI interrupt handler then what is the point of the reservation= ? > > Did I miss anything? > Yes, my original patch to Andi reworked the NMI watchdog such that set_nmi_callback() would _not_ disable it. Instead set_nmi_callback() would be used to register an NMI handler to capture interrupts the NMI subsystem didn't know what to do with (it knows NMI watchdog, memory parity errors, and i/o check errors). However, the problem arises over the new concept of the NMI watchdog never being allowed to be disabled. Since the NMI watchdog uses one of the performance counters, this conflicts with how oprofile implements its functionality. Therefore, I was trying to find a way to prevent oprofile from using whatever counter register NMI watchdog is using (as long as NMI watchdog is enabled at boot time), hence my reservation logic. I am open to suggestions of alternate ideas but this is the crux of the problem I am trying to solve. > > If this is acceptable, then I was hoping to solict some feedback on a > > good way of implementing this on the pentium models. It seems in the > > AMD systems, only a few registers are ever touched, thus making it > > easy to hack in some code. On the Intel systems, the code seems to > > touch over 100 registers for no other reason than just to clear them. > > This makes hacking more complicated. > > You have about 18 counters and they are implemented by about 80 registers= . > Yes, they can all be used it depends on what you want to measure. *blinks* I was hoping I just misread the code. This will cause my approach to be very intrusive on P4 boxes. Hopefully, we can come up with a simpler way. Cheers, Don |