From: Peter Zijlstra <peterz@infradead.org>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: acme@kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org,
tglx@linutronix.de, jolsa@kernel.org, eranian@google.com,
alexander.shishkin@linux.intel.com, ak@linux.intel.com
Subject: Re: [PATCH V2 04/23] perf/x86/intel: Support adaptive PEBSv4
Date: Fri, 22 Mar 2019 13:30:25 +0100 [thread overview]
Message-ID: <20190322123025.GS6058@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <701a0cb7-d2ae-2d55-b5ef-57f4094c994f@linux.intel.com>
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@linux.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);
> > > }
next prev parent reply other threads:[~2019-03-22 12:30 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 20:56 [PATCH V2 00/23] perf: Add Icelake support kan.liang
2019-03-21 20:56 ` [PATCH V2 01/23] perf/x86: Support outputting XMM registers kan.liang
2019-03-21 20:56 ` [PATCH V2 02/23] perf/x86/intel: Extract memory code PEBS parser for reuse kan.liang
2019-03-21 20:56 ` [PATCH V2 03/23] perf/x86/intel/ds: Extract code of event update in short period kan.liang
2019-03-21 20:56 ` [PATCH V2 04/23] perf/x86/intel: Support adaptive PEBSv4 kan.liang
2019-03-21 21:13 ` Peter Zijlstra
2019-03-21 21:17 ` Peter Zijlstra
2019-03-21 21:20 ` Peter Zijlstra
2019-03-22 0:40 ` Liang, Kan
2019-03-22 12:30 ` Peter Zijlstra [this message]
2019-03-21 20:56 ` [PATCH V2 05/23] perf/x86/lbr: Avoid reading the LBRs when adaptive PEBS handles them kan.liang
2019-03-21 20:56 ` [PATCH V2 06/23] perf/x86: Support constraint ranges kan.liang
2019-03-21 21:09 ` Peter Zijlstra
2019-03-21 20:56 ` [PATCH V2 07/23] perf/x86/intel: Add Icelake support kan.liang
2019-03-21 20:56 ` [PATCH V2 08/23] perf/x86/intel/cstate: " kan.liang
2019-03-21 20:56 ` [PATCH V2 09/23] perf/x86/intel/rapl: " kan.liang
2019-03-21 20:56 ` [PATCH V2 10/23] perf/x86/msr: " kan.liang
2019-03-21 20:56 ` [PATCH V2 11/23] perf/x86/intel/uncore: Add Intel Icelake uncore support kan.liang
2019-03-21 20:56 ` [PATCH V2 12/23] perf/core: Support a REMOVE transaction kan.liang
2019-03-21 20:56 ` [PATCH V2 13/23] perf/x86/intel: Basic support for metrics counters kan.liang
2019-03-21 20:56 ` [PATCH V2 14/23] perf/x86/intel: Support overflows on SLOTS kan.liang
2019-03-21 20:56 ` [PATCH V2 15/23] perf/x86/intel: Support hardware TopDown metrics kan.liang
2019-03-21 20:56 ` [PATCH V2 16/23] perf/x86/intel: Set correct weight for topdown subevent counters kan.liang
2019-03-21 20:56 ` [PATCH V2 17/23] perf/x86/intel: Export new top down events for Icelake kan.liang
2019-03-21 20:56 ` [PATCH V2 18/23] perf/x86/intel: Disable sampling read slots and topdown kan.liang
2019-03-21 20:56 ` [PATCH V2 19/23] perf/x86/intel: Support CPUID 10.ECX to disable fixed counters kan.liang
2019-03-21 20:57 ` [PATCH V2 20/23] perf, tools: Add support for recording and printing XMM registers kan.liang
2019-03-21 20:57 ` [PATCH V2 21/23] perf, tools, stat: Support new per thread TopDown metrics kan.liang
2019-03-21 20:57 ` [PATCH V2 22/23] perf, tools: Add documentation for topdown metrics kan.liang
2019-03-21 20:57 ` [PATCH V2 23/23] perf vendor events intel: Add JSON files for Icelake kan.liang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190322123025.GS6058@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.