All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jin, Yao" <yao.jin@linux.intel.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
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: Fri, 20 Oct 2017 06:49:10 +0800	[thread overview]
Message-ID: <adbfedcf-9a69-3a2f-e788-6a8a34bb6264@linux.intel.com> (raw)
In-Reply-To: <20171019202549.GC30002@kernel.org>



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

  reply	other threads:[~2017-10-19 22:49 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
2017-10-19 22:49       ` Jin, Yao [this message]
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=adbfedcf-9a69-3a2f-e788-6a8a34bb6264@linux.intel.com \
    --to=yao.jin@linux.intel.com \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=acme@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 \
    /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.