linux-kernel - Re: [RFC PATCH 2/3] perf tools: Add support for "report" for some spe events

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <335fedb8-128c-7d34-c5e8-15cd660fe12e@huawei.com>
Date:   Wed, 9 Oct 2019 19:49:35 +0800
From:   Tan Xiaojun <tanxiaojun@...wei.com>
To:     James Clark <James.Clark@....com>,
        Jeremy Linton <Jeremy.Linton@....com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "acme@...nel.org" <acme@...nel.org>,
        "alexander.shishkin@...ux.intel.com" 
        <alexander.shishkin@...ux.intel.com>,
        "jolsa@...hat.com" <jolsa@...hat.com>,
        "namhyung@...nel.org" <namhyung@...nel.org>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "adrian.hunter@...el.com" <adrian.hunter@...el.com>,
        "yao.jin@...ux.intel.com" <yao.jin@...ux.intel.com>,
        "tmricht@...ux.ibm.com" <tmricht@...ux.ibm.com>,
        "brueckner@...ux.ibm.com" <brueckner@...ux.ibm.com>,
        "songliubraving@...com" <songliubraving@...com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Kim Phillips <Kim.Phillips@....com>
CC:     "gengdongjiu@...wei.com" <gengdongjiu@...wei.com>,
        "wxf.wang@...ilicon.com" <wxf.wang@...ilicon.com>,
        "liwei391@...wei.com" <liwei391@...wei.com>,
        "huawei.libin@...wei.com" <huawei.libin@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
        "Al Grant" <Al.Grant@....com>, nd <nd@....com>
Subject: Re: [RFC PATCH 2/3] perf tools: Add support for "report" for some spe
 events

On 2019/10/9 19:09, Tan Xiaojun wrote:
> On 2019/10/9 17:48, James Clark wrote:
>> Hi Xiaojun,
>>
>>> By the way, you mentioned before that you want the spe event to be in the form of "event:pp" like pebs. Is that the whole framework should be made similar to pebs? Or is it just a modification to the command format? 
>>
>> We're currently still investigating if it makes sense to modify the Perf event open syscall to use SPE when the "precise_ip" attribute is set. And then synthesize samples using the SPE data when available. This would keep the syscall interface more consistent between architectures.
>>
>> And if tools other than Perf want more precise data, they don't have to be aware of SPE or any of the implementation defined details of it. For example the 'data source' encoding can be different from one micro architecture to the next. The kernel is probably the best place to handle this.
>>
>> At the moment, every tool that wants to use the Perf syscall to get precise data on ARM would have to be aware of SPE and implement their own decoding.
>>
> 
> Hi James,
> 
> What do you mean when the user specifies "event:pp", if the SPE is available, configure and record the spe data directly via the perf event open syscall?
> (perf.data itself is the same as using -e arm_spe_0//xxx?)

I mean, for the perf record, if the user does not add ":pp" to these events, the original process is taken, and if ":pp" is added, the spe process is taken.

Xiaojun.

> 
> OK. If I have not misunderstood, I think I know how to do it.
> Thank you.
> 
>>> For the former, this may be a bit difficult. For the latter, there is currently no modification to the record part, so "-c -F, etc." is only for instructions rather than events, so it may be misunderstood by users.
>>>
>>> So I haven't figured out how to do. What do you think of this?
>>
>> I think the patch at the moment is a good start to make SPE more accessible. And the changes I mentioned above wouldn't change the fact that the raw SPE data would still be available via the SPE PMU. So I think continuing with the patch as-is for now is the best idea.
>>
> 
> Yes. I agree.
> 
> Xiaojun.
> 
>>
>> James
>>
>>
>