Messages in this thread | | | Subject | Re: [RFC][PATCH] irq_work -v2 | From | Peter Zijlstra <> | Date | Sat, 26 Jun 2010 12:32:43 +0200 |
| |
On Sat, 2010-06-26 at 12:08 +0200, Andi Kleen wrote: > You could as well drop the excessive event. In fact it surprises me that you > don't simply do that in perf. The state should be in the PMU registers > anyways, so you'll pick it up from there (and if you get NMIs as quickly that > you cannot process them you have to eventually throttle by dropping anyways)
I'm not quite seeing what you mean, the PMU state is reset on PMI, it doesn't know about previous overflows, and it most certainly doesn't know if for the previous event we had to wake the buffer consumers.
For non-uniform events (like basically everything but cycles/instructions) you can get high bursts of PMIs, only when the rate stays too high will we eventually throttle, but we can (and should) deal with short periods of high rate PMIs.
The PMU is stopped during the PMI, we write out data to the buffer and possible queue a callback to wake the consumers and or de-schedule the event.
By setting the the pending op state and enqueueing the callback we ensure the pending op isn't lost/ignored. If there was already one in flight it will pick up our pending state, if not we just queued a new one.
In fact Huang argued for something very similar, so I assumed he actually needed this too.
| |