2010/1/19 Peter Zijlstra <pet...@infradead.org>: > On Tue, 2010-01-19 at 16:55 +0100, Frederic Weisbecker wrote: >> > Also, I see you set an ->unthrottle, but then don't implement it, but >> > comment it as todo, which is strange because that implies its broken. If >> > there's an ->unthrottle method it will throttle, so if its todo, the >> > safest thing is to not set it. >> >> >> Yeah, that's because I have a too vague idea on what is the purpose >> of the unthrottle() callback. >> >> I've read the concerned codes that call this, several times, and I still >> can't figure out what happens there, not sure what is meant by throttle >> or unthrottle there :-/ > > OK, so not setting it is relatively safe. > > As to what it does, it has to undo everything you do when > perf_event_overflow() returns true, which happens when ->unthrottle is > set and we get more than sysctl_perf_event_sample_rate/HZ events in a > jiffy. > > If you look at the x86 implementation, you'll see that we simply disable > the hardware counter when the overflow call returns true, so the > unthrottle() callback simply enables it again.
Ok, I understand better now what mean "throttle" and "unthrottle" here. But looking at what happens when we reach an event storm point, the pending and subsequent overflows until the next tick are just cancelled and that's it (as it's using the software overflow handler, not the x86 one). So we throttle and it's what we would want to avoid a hang. If I remove my unthrottle stub, it won't throttle anymore. Theorically, the best would be to implement a true unthrottle callback, which would just clear dr7, really trivial. But I don't like this as ptrace events must always be reported. A userspace app could be polling a watchpointed variable, causing a lot of events, may be that could trigger a storm and then perf would throttle. Sure this is not supposed to happen, given the fact ptrace breakpoints are signaled to a debugger, which reduces the possible storm windows. But just imagine a silly user sets sysctl_perf_event_sample_rate to 1, then we would throttle at each events, breaking the ptrace determinism rules. So for now, I guess I need to remove my unthrottle stub, breakpoints don't want to throttle because of the ptrace determinism requirements. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
