public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Stephane Eranian <eranian@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"mingo@elte.hu" <mingo@elte.hu>
Subject: Re: [BUG] perf report: ordered events and flushing bug
Date: Thu, 12 Mar 2015 13:34:29 -0600	[thread overview]
Message-ID: <5501EA45.8080608@gmail.com> (raw)
In-Reply-To: <CABPqkBQdvMe=vft4tuN14FrWApBHxa=wjOxjrTnkc4Uga6HGpQ@mail.gmail.com>

On 3/12/15 1:23 PM, Stephane Eranian wrote:
>> Rounds and flushing after them helps with the user experience -- at least
>> for some commands. On systems with 1024 cpus perf data files get large
>> quickly and the resulting analysis command can appear to hang for long
>> periods (e.g., i have done 1 second data collections that generate 5GB files
>> and take 30-45 minutes before perf shows any output).
>>
>> I have a patch to perf-record to allow a user to specify the poll timeout.
>> That helps define the maximum time between 'rounds' on the record side and
>> then commands that show each event (e.g, perf script) will show output much
>> more quickly without the need to consume large amounts of memory or process
>> the entire file before displaying events.
>>
> I can understand this but not at the cost of correctness. You have no guarantee
> that events will appear in the perf.data with a fixed maximum time window, i.e.,
> beyond the window, out-of-order events may be discarded.
> There ought to be a better way of keeping the user aware of what's going on
> with the progress bar.

Theoretically there are no events coming in out of order. Have you seen 
the comment before process_finished_round() in util/session.c?

In practice it did happen occasionally and perf would dump:
     Warning: Timestamp below last timeslice flush

and then terminate. That was removed recently by Jiri I think and events 
out of the window are discarded (??).

In my case I don't want a progress bar, I want output and I don't need 
the entire file processed for output to start. For a while I was 
dropping back to the ftrace interface in debugfs b/c it was faster.

For the JIT case you tried appending events at the end of the file but 
that makes them no where near the real time points so what you really 
need is to insert events into the stream. Perhaps the separate files 
option would help -- jit events in a separate file and inserted based on 
time as the files are processed?

David

  reply	other threads:[~2015-03-12 19:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12  3:32 [BUG] perf report: ordered events and flushing bug Stephane Eranian
2015-03-12  7:57 ` Namhyung Kim
2015-03-12  9:02 ` Adrian Hunter
2015-03-12 19:05   ` Stephane Eranian
2015-03-12 19:13     ` David Ahern
2015-03-12 19:23       ` Stephane Eranian
2015-03-12 19:34         ` David Ahern [this message]
2015-03-12 19:39           ` Stephane Eranian
2015-03-12 19:53             ` David Ahern
2015-03-12 20:06               ` Stephane Eranian
2015-03-12 20:50                 ` Arnaldo Carvalho de Melo
2015-03-16  1:11                   ` Namhyung Kim
2015-03-12 20:16               ` Arnaldo Carvalho de Melo
2015-03-12 20:24                 ` Stephane Eranian
2015-03-12 20:27       ` Adrian Hunter

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=5501EA45.8080608@gmail.com \
    --to=dsahern@gmail.com \
    --cc=acme@redhat.com \
    --cc=adrian.hunter@intel.com \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox