From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: peterz@infradead.org, 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
Subject: Re: [PATCH V4 04/23] perf/x86/intel: Support adaptive PEBSv4
Date: Wed, 27 Mar 2019 10:25:46 -0400 [thread overview]
Message-ID: <9d267395-fda8-d111-52a2-e7cdcdf7d24b@linux.intel.com> (raw)
In-Reply-To: <20190326222441.GP18020@tassilo.jf.intel.com>
On 3/26/2019 6:24 PM, Andi Kleen wrote:
>> + for (at = base; at < top; at += cpuc->pebs_record_size) {
>> + u64 pebs_status;
>> +
>> + pebs_status = get_pebs_status(at) & cpuc->pebs_enabled;
>> + pebs_status &= mask;
>> +
>> + for_each_set_bit(bit, (unsigned long *)&pebs_status, size)
>> + counts[bit]++;
>> + }
>
> On Icelake pebs_status is always reliable, so I don't think we need
> the two pass walking.
>
We need to call perf_event_overflow() for the last record of each event.
It's hard to detect which record is the last record of the event with
one pass walking.
Also, I'm not sure how much we can save with one pass walking. The
optimization should only benefit large PEBS. The total number of records
for large PEBS should not be huge.
I will evaluate the performance impact of one pass walking. If there is
observed performance improvement, I will submit a separate patch later.
For now, I think we can still use the mature two pass walking method.
Thanks,
Kan
> -Andi
>
>> +
>> + for (bit = 0; bit < size; bit++) {
>> + if (counts[bit] == 0)
>> + continue;
>> +
>> + event = cpuc->events[bit];
>> + if (WARN_ON_ONCE(!event))
>> + continue;
>> +
>> + if (WARN_ON_ONCE(!event->attr.precise_ip))
>> + continue;
>> +
>> + __intel_pmu_pebs_event(event, iregs, base,
>> + top, bit, counts[bit],
>> + setup_pebs_adaptive_sample_data);
>> + }
>> +}
next prev parent reply other threads:[~2019-03-27 14:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 16:08 [PATCH V4 00/23] perf: Add Icelake support kan.liang
2019-03-26 16:08 ` [PATCH V4 01/23] perf/x86: Support outputting XMM registers kan.liang
2019-04-01 19:18 ` Stephane Eranian
2019-04-01 19:54 ` Liang, Kan
2019-04-01 21:11 ` Stephane Eranian
2019-04-01 22:33 ` Liang, Kan
2019-03-26 16:08 ` [PATCH V4 02/23] perf/x86/intel: Extract memory code PEBS parser for reuse kan.liang
2019-03-26 16:08 ` [PATCH V4 03/23] perf/x86/intel/ds: Extract code of event update in short period kan.liang
2019-03-26 16:08 ` [PATCH V4 04/23] perf/x86/intel: Support adaptive PEBSv4 kan.liang
2019-03-26 22:24 ` Andi Kleen
2019-03-27 14:25 ` Liang, Kan [this message]
2019-03-27 14:42 ` Andi Kleen
2019-03-26 16:08 ` [PATCH V4 05/23] perf/x86/lbr: Avoid reading the LBRs when adaptive PEBS handles them kan.liang
2019-03-26 16:08 ` [PATCH V4 06/23] perf/x86: Support constraint ranges kan.liang
2019-03-26 16:08 ` [PATCH V4 07/23] perf/x86/intel: Add Icelake support kan.liang
2019-03-26 16:08 ` [PATCH V4 08/23] perf/x86/intel/cstate: " kan.liang
2019-03-26 16:08 ` [PATCH V4 09/23] perf/x86/intel/rapl: " kan.liang
2019-03-26 16:08 ` [PATCH V4 10/23] perf/x86/msr: " kan.liang
2019-03-26 16:08 ` [PATCH V4 11/23] perf/x86/intel/uncore: Add Intel Icelake uncore support kan.liang
2019-03-26 16:08 ` [PATCH V4 12/23] perf/core: Support a REMOVE transaction kan.liang
2019-03-26 16:08 ` [PATCH V4 13/23] perf/x86/intel: Basic support for metrics counters kan.liang
2019-03-26 16:08 ` [PATCH V4 14/23] perf/x86/intel: Support overflows on SLOTS kan.liang
2019-03-26 16:08 ` [PATCH V4 15/23] perf/x86/intel: Support hardware TopDown metrics kan.liang
2019-03-26 16:08 ` [PATCH V4 16/23] perf/x86/intel: Set correct weight for topdown subevent counters kan.liang
2019-03-26 16:08 ` [PATCH V4 17/23] perf/x86/intel: Export new top down events for Icelake kan.liang
2019-03-26 16:08 ` [PATCH V4 18/23] perf/x86/intel: Disable sampling read slots and topdown kan.liang
2019-03-26 16:08 ` [PATCH V4 19/23] perf/x86/intel: Support CPUID 10.ECX to disable fixed counters kan.liang
2019-03-26 16:08 ` [PATCH V4 20/23] perf, tools: Add support for recording and printing XMM registers kan.liang
2019-03-26 16:08 ` [PATCH V4 21/23] perf, tools, stat: Support new per thread TopDown metrics kan.liang
2019-03-26 16:09 ` [PATCH V4 22/23] perf, tools: Add documentation for topdown metrics kan.liang
2019-03-26 16:09 ` [PATCH V4 23/23] perf vendor events intel: Add JSON files for Icelake kan.liang
2019-04-01 13:01 ` [PATCH V4 00/23] perf: Add Icelake support Liang, Kan
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=9d267395-fda8-d111-52a2-e7cdcdf7d24b@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox