All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@arm.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org, Atish Patra <atishp@rivosinc.com>,
	linux-riscv@lists.infradead.org,
	Beeman Strong <beeman@rivosinc.com>
Subject: Re: [PATCH v2 13/16] perf parse-events: Improvements to modifier parsing
Date: Wed, 24 Apr 2024 11:30:14 -0400	[thread overview]
Message-ID: <7f1014fc-eb0a-4989-8efa-245d5b6937cd@linux.intel.com> (raw)
In-Reply-To: <CAP-5=fUi8DPNrbp=978K92Mopa71ag1sukttX3KcztD2ac0ADg@mail.gmail.com>



On 2024-04-24 11:18 a.m., Ian Rogers wrote:
> On Fri, Apr 19, 2024 at 6:20 AM Liang, Kan <kan.liang@linux.intel.com> wrote:
>>
>>
>>
>> On 2024-04-19 2:22 a.m., Ian Rogers wrote:
>>>>> +             /* Simple modifiers copied to the evsel. */
>>>>> +             if (mod.precise) {
>>>>> +                     u8 precise = evsel->core.attr.precise_ip + mod.precise;
>>>>> +                     /*
>>>>> +                      * precise ip:
>>>>> +                      *
>>>>> +                      *  0 - SAMPLE_IP can have arbitrary skid
>>>>> +                      *  1 - SAMPLE_IP must have constant skid
>>>>> +                      *  2 - SAMPLE_IP requested to have 0 skid
>>>>> +                      *  3 - SAMPLE_IP must have 0 skid
>>>>> +                      *
>>>>> +                      *  See also PERF_RECORD_MISC_EXACT_IP
>>>>> +                      */
>>>>> +                     if (precise > 3) {
>>>> The pmu_max_precise() should return the max precise the current kernel
>>>> supports. It checks the /sys/devices/cpu/caps/max_precise.
>>>>
>>>> I think we should use that value rather than hard code it to 3.
>>> I'll add an extra patch to do that. I'm a bit concerned it may break
>>> event parsing on platforms not supporting max_precise of 3.
>>
>> The kernel already rejects the precise_ip > max_precise (using the same
>> x86_pmu_max_precise()). It should be fine to apply the same logic in the
>> tool.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/events/core.c#n566
>>
>> Will the extra patch be sent separately?
> 
> Let's do it separately. I'm concerned about the behavior on AMD (and
> possibly similar architectures) where certain events support precision
> like cycles, as they detour to the IBS PMU, but not all events support
> it. The max_precise should reflect that AMD's Zen core PMU does
> support precision as a consequence of detouring to IBS, but maybe
> things in sysfs aren't set up correctly.
> 

The x86_pmu_max_precise() is a generic function for X86. It should apply
to AMD as well.

A separate patch looks good to me.

Thanks,
Kan


WARNING: multiple messages have this Message-ID (diff)
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@arm.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org, Atish Patra <atishp@rivosinc.com>,
	linux-riscv@lists.infradead.org,
	Beeman Strong <beeman@rivosinc.com>
Subject: Re: [PATCH v2 13/16] perf parse-events: Improvements to modifier parsing
Date: Wed, 24 Apr 2024 11:30:14 -0400	[thread overview]
Message-ID: <7f1014fc-eb0a-4989-8efa-245d5b6937cd@linux.intel.com> (raw)
In-Reply-To: <CAP-5=fUi8DPNrbp=978K92Mopa71ag1sukttX3KcztD2ac0ADg@mail.gmail.com>



On 2024-04-24 11:18 a.m., Ian Rogers wrote:
> On Fri, Apr 19, 2024 at 6:20 AM Liang, Kan <kan.liang@linux.intel.com> wrote:
>>
>>
>>
>> On 2024-04-19 2:22 a.m., Ian Rogers wrote:
>>>>> +             /* Simple modifiers copied to the evsel. */
>>>>> +             if (mod.precise) {
>>>>> +                     u8 precise = evsel->core.attr.precise_ip + mod.precise;
>>>>> +                     /*
>>>>> +                      * precise ip:
>>>>> +                      *
>>>>> +                      *  0 - SAMPLE_IP can have arbitrary skid
>>>>> +                      *  1 - SAMPLE_IP must have constant skid
>>>>> +                      *  2 - SAMPLE_IP requested to have 0 skid
>>>>> +                      *  3 - SAMPLE_IP must have 0 skid
>>>>> +                      *
>>>>> +                      *  See also PERF_RECORD_MISC_EXACT_IP
>>>>> +                      */
>>>>> +                     if (precise > 3) {
>>>> The pmu_max_precise() should return the max precise the current kernel
>>>> supports. It checks the /sys/devices/cpu/caps/max_precise.
>>>>
>>>> I think we should use that value rather than hard code it to 3.
>>> I'll add an extra patch to do that. I'm a bit concerned it may break
>>> event parsing on platforms not supporting max_precise of 3.
>>
>> The kernel already rejects the precise_ip > max_precise (using the same
>> x86_pmu_max_precise()). It should be fine to apply the same logic in the
>> tool.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/events/core.c#n566
>>
>> Will the extra patch be sent separately?
> 
> Let's do it separately. I'm concerned about the behavior on AMD (and
> possibly similar architectures) where certain events support precision
> like cycles, as they detour to the IBS PMU, but not all events support
> it. The max_precise should reflect that AMD's Zen core PMU does
> support precision as a consequence of detouring to IBS, but maybe
> things in sysfs aren't set up correctly.
> 

The x86_pmu_max_precise() is a generic function for X86. It should apply
to AMD as well.

A separate patch looks good to me.

Thanks,
Kan


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2024-04-24 15:30 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16  6:15 [PATCH v2 00/16] Consistently prefer sysfs/json events Ian Rogers
2024-04-16  6:15 ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 01/16] perf parse-events: Factor out '<event_or_pmu>/.../' parsing Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 02/16] perf parse-events: Directly pass PMU to parse_events_add_pmu Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 03/16] perf parse-events: Avoid copying an empty list Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 04/16] perf pmu: Refactor perf_pmu__match Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 05/16] perf tests parse-events: Use branches rather than cache-references Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 06/16] perf parse-events: Legacy cache names on all PMUs and lower priority Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 07/16] perf parse-events: Handle PE_TERM_HW in name_or_raw Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 08/16] perf parse-events: Constify parse_events_add_numeric Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 09/16] perf parse-events: Prefer sysfs/json hardware events over legacy Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 10/16] perf parse-events: Inline parse_events_update_lists Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 11/16] perf parse-events: Improve error message for bad numbers Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-18 20:27   ` Liang, Kan
2024-04-18 20:27     ` Liang, Kan
2024-04-18 21:07     ` Ian Rogers
2024-04-18 21:07       ` Ian Rogers
2024-04-19 13:29       ` Liang, Kan
2024-04-19 13:29         ` Liang, Kan
2024-04-27  1:35   ` Arnaldo Carvalho de Melo
2024-04-27  1:35     ` Arnaldo Carvalho de Melo
2024-04-27  1:36     ` Arnaldo Carvalho de Melo
2024-04-27  1:36       ` Arnaldo Carvalho de Melo
2024-04-27 22:05       ` Ian Rogers
2024-04-27 22:05         ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 12/16] perf parse-events: Inline parse_events_evlist_error Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 13/16] perf parse-events: Improvements to modifier parsing Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-18 20:32   ` Liang, Kan
2024-04-18 20:32     ` Liang, Kan
2024-04-19  6:22     ` Ian Rogers
2024-04-19  6:22       ` Ian Rogers
2024-04-19 13:20       ` Liang, Kan
2024-04-19 13:20         ` Liang, Kan
2024-04-24 15:18         ` Ian Rogers
2024-04-24 15:18           ` Ian Rogers
2024-04-24 15:30           ` Liang, Kan [this message]
2024-04-24 15:30             ` Liang, Kan
2024-04-16  6:15 ` [PATCH v2 14/16] perf parse-event: Constify event_symbol arrays Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 15/16] perf parse-events: Minor grouping tidy up Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-16  6:15 ` [PATCH v2 16/16] perf parse-events: Tidy the setting of the default event name Ian Rogers
2024-04-16  6:15   ` Ian Rogers
2024-04-24  0:28 ` [PATCH v2 00/16] Consistently prefer sysfs/json events Atish Kumar Patra
2024-04-24  0:28   ` Atish Kumar Patra
2024-04-24 15:14   ` Ian Rogers
2024-04-24 15:14     ` Ian Rogers
2024-04-24 15:34 ` Liang, Kan
2024-04-24 15:34   ` 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=7f1014fc-eb0a-4989-8efa-245d5b6937cd@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=atishp@rivosinc.com \
    --cc=beeman@rivosinc.com \
    --cc=bpf@vger.kernel.org \
    --cc=irogers@google.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /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.