From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jin Yao <yao.jin@linux.intel.com>
Cc: jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com,
alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org,
ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com
Subject: Re: [PATCH v4 2/6] perf record: Get the first sample time and last sample time
Date: Thu, 19 Oct 2017 17:25:49 -0300 [thread overview]
Message-ID: <20171019202549.GC30002@kernel.org> (raw)
In-Reply-To: <20171019202127.GB30002@kernel.org>
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@linux.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
next prev parent reply other threads:[~2017-10-19 20:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-03 14:22 [PATCH v4 0/6] perf report/script: Support percent and multiple range in --time option Jin Yao
2017-10-03 14:22 ` [PATCH v4 1/6] perf header: Record first sample time and last sample time in perf file header Jin Yao
2017-10-19 20:17 ` Arnaldo Carvalho de Melo
2017-10-03 14:22 ` [PATCH v4 2/6] perf record: Get the first sample time and last sample time Jin Yao
2017-10-19 20:21 ` Arnaldo Carvalho de Melo
2017-10-19 20:25 ` Arnaldo Carvalho de Melo [this message]
2017-10-19 22:49 ` Jin, Yao
2017-10-03 14:22 ` [PATCH v4 3/6] perf util: Create function to parse time percent Jin Yao
2017-10-03 14:22 ` [PATCH v4 4/6] perf util: Create function to perform multiple time range checking Jin Yao
2017-10-03 14:22 ` [PATCH v4 5/6] perf report: support time percent and multiple time ranges Jin Yao
2017-10-03 14:22 ` [PATCH v4 6/6] perf script: " Jin Yao
2017-10-05 8:50 ` [PATCH v4 0/6] perf report/script: Support percent and multiple range in --time option Jiri Olsa
2017-10-18 7:19 ` Jin, Yao
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=20171019202549.GC30002@kernel.org \
--to=acme@kernel.org \
--cc=Linux-kernel@vger.kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=yao.jin@intel.com \
--cc=yao.jin@linux.intel.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.