From: Namhyung Kim <namhyung@kernel.org>
To: David Ahern <dsahern@gmail.com>
Cc: "Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Jiri Olsa" <jolsa@kernel.org>, "Ingo Molnar" <mingo@kernel.org>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: heads up/RFC: 'perf trace' using ordered_events
Date: Wed, 11 Mar 2015 09:33:57 +0900 [thread overview]
Message-ID: <20150311003357.GH943@sejong> (raw)
In-Reply-To: <54FEFED7.5000503@gmail.com>
Hi David,
On Tue, Mar 10, 2015 at 08:25:27AM -0600, David Ahern wrote:
> On 3/10/15 12:06 AM, Namhyung Kim wrote:
> >Hi Arnaldo,
> >
> >On Mon, Mar 09, 2015 at 10:21:35AM -0300, Arnaldo Carvalho de Melo wrote:
> >>For trace I need to take advantage of the fact that each mmap is ordered
> >>already and then just sort by the timestamp in the mmap head, etc.
> >>
> >>In retrospect, the perf.data file should have kept that ordering, i.e.
> >>have one file per mmap, that would be saved in parallel, without any of
> >>those PERF_RECORD_FINISHED_ROUND records.
> >>
> >>But I have to experiment with that, leaving the existing code around to
> >>deal with older files.
> >
> >It seems like what you said is almost same as my multi-thread work.
> >It saves data files per mmap and then merges them with an index
> >table so that they can be processed in parallel.
>
> I think you and Jiri both have worked on saving a file per mmap. Where does
> that stand? I would like to try it out.
It's available on perf/threaded-v3 branch in my tree.
You can see the description and numbers at
https://lkml.org/lkml/2015/3/2/988.
Also you can index your data file and then process with multi-thread:
$ perf data index -i perf.data -o perf.data.idx
$ perf report --multi-thread -i perf.data.idx
Thanks,
Namhyung
>
> With the 1024 cpu systems I am seeing 5GB files in 1 second runs and perf is
> not handling it well. The perf-script/perf-report (stdio) will 'hang' for 45
> minutes munging through the file. I have to connect gdb from time to time to
> verify it is making progress (file_offset is increasing). I believe what
> happens is that there is 'no round' -- it has to process all mmaps (1024
> cpus and 6 or 7 events) through the ordered events queue before it can push
> out results. I need to look at that once I figure out the task scheduler
> problem.
>
> David
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
prev parent reply other threads:[~2015-03-11 0:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 16:49 heads up/RFC: 'perf trace' using ordered_events Arnaldo Carvalho de Melo
2015-03-04 1:01 ` Namhyung Kim
2015-03-04 1:07 ` Arnaldo Carvalho de Melo
2015-03-07 12:45 ` Adrian Hunter
2015-03-09 13:21 ` Arnaldo Carvalho de Melo
2015-03-10 6:06 ` Namhyung Kim
2015-03-10 14:25 ` David Ahern
2015-03-11 0:33 ` Namhyung Kim [this message]
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=20150311003357.GH943@sejong \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=dsahern@gmail.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.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 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.