Messages in this thread | | | Date | Thu, 5 Jan 2012 13:31:27 +0000 | Subject | Re: perf_events: proposed fix for broken intr throttling (repost) | From | Stephane Eranian <> |
| |
On Thu, Jan 5, 2012 at 1:19 PM, Gleb Natapov <gleb@redhat.com> wrote: > On Thu, Jan 05, 2012 at 01:08:41PM +0000, Stephane Eranian wrote: >> Peter, >> >> I looked into this some more this morning. I don't think your proposed >> scheme can work. >> Unless, I misunderstood you, you were suggesting that we could perhaps >> use a lazy >> approach in perf_event_task_tick() and walk the event list only when >> we have, at least, one >> event to unthrottle, i.e., similar to what is done with nr_freq. That >> cannot work. The problem is >> that you'd let all events get throttled before you'd unthrottle them >> in the next timer tick. >> At each overflow, hwc->interrupt would get incremented until it >> reached MAX_INTERRUPTS. >> Then, the event would be stopped (throttled), you'd do >> ctx->nr_throttled = 1. At the next >> timer tick, perf_event_task_tick() would then unthrottle the event. In >> that scheme, the >> event would be throttled for at most a tick. But in fact, the event >> never generated that >> many overflows/tick to justify throttling. >> >> I think there is no other way than what I suggested in my initial email: >> 1- revert the nr_freq optimization >> 2- reset hwc->interrupt on all events at each tick >> > I think my original patch did that: https://lkml.org/lkml/2011/11/15/114 > Yes, looks like it, because it is systematically calling perf_ctx_adjust_freq() which does reset the hwc->interrupts counter on ALL events.
But the pmu_disabled trick is not very pretty. We have to find some middle ground solution here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |