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

Date:   Thu, 19 Oct 2017 17:25:49 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Jin Yao <yao.jin@...ux.intel.com>
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

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
 
> - Arnaldo
> 
> > the first/last samples and save the time to perf file header via the
> > function write_sample_time().
> > 
> > In later, perf report/script will fetch the time from perf file header.
> > 
> > Change log:
> > -----------
> > v3: Remove the definitions of first_sample_time and last_sample_time
> >     from struct record and directly save them in perf_evlist.
> > 
> > Signed-off-by: Jin Yao <yao.jin@...ux.intel.com>
> > ---
> >  tools/perf/builtin-record.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> > index 9b379f3..d5b78449 100644
> > --- a/tools/perf/builtin-record.c
> > +++ b/tools/perf/builtin-record.c
> > @@ -488,6 +488,11 @@ static int process_sample_event(struct perf_tool *tool,
> >  
> >  	rec->samples++;
> >  
> > +	if (rec->evlist->first_sample_time == 0)
> > +		rec->evlist->first_sample_time = sample->time;
> > +
> > +	rec->evlist->last_sample_time = sample->time;
> > +
> >  	return build_id__mark_dso_hit(tool, event, sample, evsel, machine);
> >  }
> >  
> > -- 
> > 2.7.4