On Wed, May 24, 2017 at 9:01 AM, Vince Weaver <vincent.wea...@maine.edu> wrote: > > On Wed, 24 May 2017, Andi Kleen wrote: > > > > Right, I did not even consider the rdpmc, but yeah, you will get a count > > > that > > > is not relevant to the user visible event. Unless you fake it using the > > > time > > > scaling fields there but that's ugly. > > > > Could add another scaling field to the mmap page for this. > > The whole point of the rdpmc() implementation is to be low overhead. > If you have to parse 10 different mmap() fields it starts to defeat the > purpose. > > I already have people really grumpy that you have to have one mmap() page > per event, meaning you sacrifice one TLB entry for each event you are > measuring. > > > If the watchdog counter is constantly running, can't you just modify > perf_event to just grab start/stop values at context switch time and > provide the difference to the user? Sort of like the "always running" > patchsets that float around? Though I guess that doesn't help much with > sampling. > This goes back to my initial point of simply increasing the period to avoid false positive and stay with the core-cycle event. It is much simpler. And again, if you are deadlocked, it should not matter if you detect it after 2mn or 5mn or 10mn. The accuracy is not so critical. And by choosing a large enough period, you avoid the issue with Turbo, even if you consider Turbo being able to double your reference frequency.
Ultimately, I would like to see the watchdog move out of the PMU. That is the only sensible solution. You just need a resource able to interrupt on NMI or you handle interrupt masking in software as has been proposed on LKML.