All of lore.kernel.org
 help / color / mirror / Atom feed
From: kajoljain <kjain@linux.ibm.com>
To: Kim Phillips <kim.phillips@amd.com>,
	Sandipan Das <sandipan.das@amd.com>, Jiri Olsa <jolsa@redhat.com>,
	acme@kernel.org
Cc: ravi.bangoria@amd.com, ananth.narayan@amd.com, rrichter@amd.com,
	linux-perf-users@vger.kernel.org, namhyung@kernel.org,
	alexander.shishkin@linux.intel.com, mark.rutland@arm.com
Subject: Re: [RFC PATCH] tools/perf/x86: Use alternative format for AMD raw events
Date: Wed, 17 Nov 2021 19:43:58 +0530	[thread overview]
Message-ID: <0fd4cf27-87a7-2beb-fa02-6a810462829e@linux.ibm.com> (raw)
In-Reply-To: <301c0693-f982-1769-6e3f-8b77a4201a69@amd.com>



On 11/16/21 9:31 PM, Kim Phillips wrote:
> On 11/15/21 10:38 PM, kajoljain wrote:
>> On 11/15/21 3:28 PM, Sandipan Das wrote:
>>>
>>> On 11/14/2021 10:11 PM, Jiri Olsa wrote:
>>>> good question.. I see raw events as a way to put to config whatever
>>>> the user wants and IMO adding changes/quirks that silently changes
>>>> config could create confusion and angry users ;-)
>>>>
>>
>> I agree, making quirks in config will only going to confuse users as
>> It's against the encodings we had in
>> /sys/bus/event_source/devices/<pmu>/format/*
>>
>>>> I'd think that if user is composing/using raw events then using
>>>> directly r100001f8e is not such a big deal?
>>>>
>>>
>>> Sure. Some of the confusion may be due to the fact that the man pages
>>> for perf-{stat,record,top} state that raw events are "eventsel+umask".
>>> While that is technically true, it does not describe the encoding
>>> scheme (/sys/bus/event_source/devices/<pmu>/format/*)
>>>
>>> Would another option be to update the man pages with a reference to
>>> these sysfs files when describing raw events?
>>>
>>> Something like:
>>>
>>> diff --git a/tools/perf/Documentation/perf-record.txt
>>> b/tools/perf/Documentation/perf-record.txt
>>> index 2d7df8703cf2..5dfdfeba594b 100644
>>> --- a/tools/perf/Documentation/perf-record.txt
>>> +++ b/tools/perf/Documentation/perf-record.txt
>>> @@ -30,8 +30,10 @@ OPTIONS
>>>
>>>           - a symbolic event name        (use 'perf list' to list all
>>> events)
>>>
>>> -        - a raw PMU event (eventsel+umask) in the form of rNNN where
>>> NNN is a
>>> -         hexadecimal event descriptor.
>>> +        - a raw PMU event (eventsel+umask) in the form of rN..NN
>>> where N..NN
>>> +          is a hexadecimal value representing the raw encoding with
>>> the layout
>>> +          of the corresponding event control register as defined by
>>> entries in
>>> +          /sys/bus/event_sources/devices/<pmu>/format/*
>>
>> Do we need to specify (eventsel+umask) in the raw event description? As
>> the format/fields totally depend on PMU and umask name convention is
>> specific to one arch.
>>
>> Can we just update it to:
>>
>> - a raw PMU event in the form of rNNN where NNN is a hexadecimal value
>> representing the raw encoding, with the layout of the corresponding
>> event control register as defined by entries in
>> /sys/bus/event_sources/devices/<pmu>/format/*
> 
> The r notation is for the cpu pmu only.
> 
> The triple-digit 'NNN' is what's most misleading for 12-bit
> event implementation users, such as AMD's core PMUs.  It
> tells users 'see your processor's documentation's triple-
> hex-digit PMCx18e event?  All you need to do is make that
> "-e r18e" on the perf stat/record command line.
> 
> So all notions of what size of parameter 'r' takes, esp. 'NNN'
> should be removed IMO.  Perhaps an AMD/12-bit-specific
> example can be provided.

I agree. Maybe we can remove specification of digits with r
and separately specify for  different scenario like AMD/12-bit-specific.
Can we use something like r<hex-digit> ?

Thanks,
Kajol Jain

> 
> I had thought that the shorthand command line r spec alone
> could be modified to be smarter and more accommodating
> for conventional rUUEE users migrating to AMD/12-bit,
> which AFAICT is not what this patch does.  I think it
> modifies even the  cpu/config=0xNNNNN/ specification,
> which, granted, is bad.
> 
> Thanks,
> 
> Kim

  reply	other threads:[~2021-11-17 14:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 12:56 [RFC PATCH] tools/perf/x86: Use alternative format for AMD raw events Sandipan Das
2021-11-14 16:41 ` Jiri Olsa
2021-11-15  9:58   ` Sandipan Das
2021-11-16  4:38     ` kajoljain
2021-11-16 16:01       ` Kim Phillips
2021-11-17 14:13         ` kajoljain [this message]
2021-11-18  7:28         ` Sandipan Das
2021-11-18 16:51           ` Kim Phillips
2021-11-28 15:36             ` Jiri Olsa

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=0fd4cf27-87a7-2beb-fa02-6a810462829e@linux.ibm.com \
    --to=kjain@linux.ibm.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=ananth.narayan@amd.com \
    --cc=jolsa@redhat.com \
    --cc=kim.phillips@amd.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=namhyung@kernel.org \
    --cc=ravi.bangoria@amd.com \
    --cc=rrichter@amd.com \
    --cc=sandipan.das@amd.com \
    /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.