linux-kernel - Re: [PATCH v4 2/6] perf record: Get the first sample time and last sample time

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

Message-ID: <adbfedcf-9a69-3a2f-e788-6a8a34bb6264@linux.intel.com>
Date:   Fri, 20 Oct 2017 06:49:10 +0800
From:   "Jin, Yao" <yao.jin@...ux.intel.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     jolsa@...nel.org, peterz@...radead.org, mingo@...hat.com,
        alexander.shishkin@...ux.intel.com, Linux-kernel@...r.kernel.org,
        ak@...ux.intel.com, kan.liang@...el.com, yao.jin@...el.com
Subject: Re: [PATCH v4 2/6] perf record: Get the first sample time and last
 sample time

On 10/20/2017 4:25 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 19, 2017 at 05:21:27PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Tue, Oct 03, 2017 at 10:22:34PM +0800, Jin Yao escreveu:
>>> In perf record, it's walked on all samples yet. So it's very easy to get
>>
>> You're saying that perf record walks all samples always? That only
>> happens when we generate the build-id table, right? And people disable
>> that to speed up the process, knowing that some limitations will come
>> from that, for doing analysis right after running it is mostly OK to
>> disable the build-id processing.
> 
> So either you add a new option that processes all events without doing
> build-id processing (and all the locking, struct thread, map, etc
> processing it entails) and just looks at the sample->time, and when
> build id processing is enabled, just do as you're doing in this patch,
> then, at perf report --time you should look to see if those start/end
> times were filled in and if not tell that to the user, i.e. that
> either --record-time-boundaries (or a better name :-) ) has to be used,
> or, that build-id process, with a short explanation that
> --record-time-boundaries is a bit cheaper.
> 
> - Arnaldo
>   

Hi Arnaldo,

Thanks so much for reminding me that the walking only happens when 
build-id processing is enabled. Yes, the step is same as what you said 
so there will be an issue when the build-id processing is disabled.

According to your suggestion, I will provide a new option 
"--record-time-boundaries" in perf record. If user disables the build-id 
processing, the perf record will ask user to set the 
"--record-time-boundaries". If user enables the build-id processing, the 
perf record will not ask user to set the "--record-time-boundaries".

Also in perf report, if it doesn't see start/end time filled in the perf 
file header, it will show some information to let user know he should 
set "--record-time-boundaries" or enable the build-id processing in perf 
record.

I will provide v5 patch series, maybe some days later.

Thanks
Jin Yao