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
>>
>>
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ