On Wed, Dec 28, 2016 at 02:31:06PM +0100, Jiri Olsa wrote: > This patch fixes following WARNING: > > WARNING: CPU: 15 PID: 15768 at arch/x86/events/core.c:1256 > x86_pmu_start+0x1b3/0x1c0 > ... > Call Trace: > <IRQ> > dump_stack+0x86/0xc3 > __warn+0xcb/0xf0 > warn_slowpath_null+0x1d/0x20 > x86_pmu_start+0x1b3/0x1c0 > perf_event_task_tick+0x342/0x3f0 > scheduler_tick+0x75/0xd0 > update_process_times+0x47/0x60 > tick_sched_handle.isra.19+0x25/0x60 > tick_sched_timer+0x3d/0x70 > __hrtimer_run_queues+0xfb/0x510 > hrtimer_interrupt+0x9d/0x1a0 > local_apic_timer_interrupt+0x38/0x60 > smp_trace_apic_timer_interrupt+0x56/0x25a > trace_apic_timer_interrupt+0x9d/0xb0 > ... > > which happens AFAICS under following conditions: > (we have PEBS events configured) > > - x86_pmu_enable reconfigures counters and calls: > - x86_pmu_stop on PEBS event > - x86_pmu_stop drains the PEBS buffer, crosses > the throttle limit and sets: > event->hw.interrupts = MAX_INTERRUPTS > - following x86_pmu_start call starts the event > - perf_event_task_tick is triggered > - perf_adjust_freq_unthr_context sees event with > MAX_INTERRUPTS set and calls x86_pmu_start on already > started event, which triggers the warning > > My first attempt to fix this was to unthrottle the event > before starting it in x86_pmu_enable. But I think that > omitting the throttling completely when we are not in the > PMI is better.
Hurm,.. good catch that. Makes a bit of a mess of things though. Then again, I cannot quickly think of something better either :/
