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] [day] [month] [year] [list]
Message-ID: <20190322123025.GS6058@hirez.programming.kicks-ass.net>
Date:   Fri, 22 Mar 2019 13:30:25 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Liang, Kan" <kan.liang@...ux.intel.com>
Cc:     acme@...nel.org, mingo@...hat.com, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, jolsa@...nel.org, eranian@...gle.com,
        alexander.shishkin@...ux.intel.com, ak@...ux.intel.com
Subject: Re: [PATCH V2 04/23] perf/x86/intel: Support adaptive PEBSv4

On Thu, Mar 21, 2019 at 08:40:03PM -0400, Liang, Kan wrote:
> 
> 
> On 3/21/2019 5:20 PM, Peter Zijlstra wrote:
> > On Thu, Mar 21, 2019 at 01:56:44PM -0700, kan.liang@...ux.intel.com wrote:
> > > @@ -933,6 +1001,34 @@ pebs_update_state(bool needed_cb, struct cpu_hw_events *cpuc, struct pmu *pmu)
> > >   		update = true;
> > >   	}
> > > +	/*
> > > +	 * The PEBS record doesn't shrink on the del. Because to get
> > > +	 * an accurate config needs to go through all the existing pebs events.
> > > +	 * It's not necessary.
> > > +	 * There is no harmful for a bigger PEBS record, except little
> > > +	 * performance impacts.
> > > +	 * Also, for most cases, the same pebs config is applied for all
> > > +	 * pebs events.
> > > +	 */
> > > +	if (x86_pmu.intel_cap.pebs_baseline && add) {
> > > +		u64 pebs_data_cfg;
> > > +
> > > +		/* Clear pebs_data_cfg and pebs_record_size for first PEBS. */
> > > +		if (cpuc->n_pebs == 1) {
> > > +			cpuc->pebs_data_cfg = 0;
> > > +			cpuc->pebs_record_size = sizeof(struct pebs_basic);
> > > +		}
> > 
> > Argh, no. This is daft. The previous site was fine, it was just the
> > pebs_record_size assignment I'm confused about.
> > 
> > Note how by setting ->pebs_data_cfs to 0, you force the below branch to
> > true and call adaptive_pebs_record_size_update() ? So _why_ do you have
> > to set pebs_record_size()?
> > 
> 
> I think we have to reset both cpuc->pebs_data_cfg and
> cpuc->pebs_record_size. Because pebs_update_adaptive_cfg() can return 0.
> If so, adaptive_pebs_record_size_update() will not be called. The
> cpuc->pebs_record_size still use the stale data, which may be wrong.

Oh, bugger.. I see.

> > > +
> > > +		pebs_data_cfg = pebs_update_adaptive_cfg(event);
> > > +
> > > +		/* Update pebs_record_size if new event requires more data. */
> > > +		if (pebs_data_cfg & ~cpuc->pebs_data_cfg) {
> > > +			cpuc->pebs_data_cfg |= pebs_data_cfg;
> > > +			adaptive_pebs_record_size_update();
> > > +			update = true;
> > > +		}
> > > +	}
> > > +
> > >   	if (update)
> > >   		pebs_update_threshold(cpuc);
> > >   }

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ