From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754176AbcLNSQl (ORCPT <rfc822;w@1wt.eu>);
        Wed, 14 Dec 2016 13:16:41 -0500
Received: from mx1.redhat.com ([209.132.183.28]:54354 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753182AbcLNSQj (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 14 Dec 2016 13:16:39 -0500
Date: Wed, 14 Dec 2016 19:16:36 +0100
From: Jiri Olsa <jolsa@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andi Kleen <andi@firstfloor.org>, lkml <linux-kernel@vger.kernel.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Vince Weaver <vince@deater.net>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [RFC] perf/x86/intel: Account interrupts for PEBS errors
Message-ID: <20161214181636.GA14741@krava>
References: <20161214165036.GB9180@krava>
 <20161214180730.GR3124@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161214180730.GR3124@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 14 Dec 2016 18:16:38 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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