On Wed, Dec 14, 2016 at 07:07:30PM +0100, Peter Zijlstra wrote:
> On Wed, Dec 14, 2016 at 05:50:36PM +0100, Jiri Olsa wrote:
> >
> > I also fail to reproduce on other than snb_x (model 45) server
>
> reproduces on my ivb-ep as well model 62.
>
> > thoughts?
>
> cute find :-)
>
> > +++ b/arch/x86/events/intel/ds.c
> > @@ -1389,9 +1389,13 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs
> > *iregs)
> > continue;
> >
> > /* log dropped samples number */
> > - if (error[bit])
> > + if (error[bit]) {
> > perf_log_lost_samples(event, error[bit]);
> >
> > + if (perf_event_account_interrupt(event, 1))
>
> Seems a bit daft to expose the .throttle argument, since that would be
> the only point of calling this.
there's also the other caller from __perf_event_overflow
> > +static int __perf_event_overflow(struct perf_event *event,
> > + int throttle, struct perf_sample_data *data,
> > + struct pt_regs *regs)
> > +{
> > + int events = atomic_read(&event->event_limit);
> > + struct hw_perf_event *hwc = &event->hw;
> > + int ret = 0;
> > +
> > + /*
> > + * Non-sampling counters might still use the PMI to fold short
> > + * hardware counters, ignore those.
> > + */
> > + if (unlikely(!is_sampling_event(event)))
> > + return 0;
> > +
> > + ret = perf_event_account_interrupt(event, throttle);
> > +
> > if (event->attr.freq) {
> > u64 now = perf_clock();
> > s64 delta = now - hwc->freq_time_stamp;
>
> Arguably, everything in __perf_event_overflow() except for calling of
> ->overflow_handler() should be done I think.
well, I was wondering about that period adjustment bit
but I wasn't sure about those pending_kill/pending_wakeup bits,
they make sense to me only if we have some data to deliver
jirka
