linux-kernel - Re: [RFC] perf/x86/intel: Account interrupts for PEBS errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161215071433.GA16047@krava>
Date:   Thu, 15 Dec 2016 08:14:33 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Andi Kleen <andi@...stfloor.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Vince Weaver <vince@...ter.net>, Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC] perf/x86/intel: Account interrupts for PEBS errors

On Wed, Dec 14, 2016 at 08:32:39PM +0100, Peter Zijlstra wrote:
> On Wed, Dec 14, 2016 at 07:16:36PM +0100, Jiri Olsa wrote:
> 
> > > > +++ 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
> 
> See the below patchlet ;-)

ok, np ;-)

> 
> > > > +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
> 
> Hmm, maybe. Please add a comment, that way we can at least rediscover we
> thought about this.

ook

jirka