[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1405893363-21967-1-git-send-email-jolsa@kernel.org>
Date: Sun, 20 Jul 2014 23:55:44 +0200
From: Jiri Olsa <jolsa@...nel.org>
To: linux-kernel@...r.kernel.org
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
David Ahern <dsahern@...il.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Jean Pihet <jean.pihet@...aro.org>,
Namhyung Kim <namhyung@...nel.org>,
Paul Mackerras <paulus@...ba.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Jiri Olsa <jolsa@...nel.org>
Subject: [PATCHv3 00/19] perf tools: Factor ordered samples queue
hi,
this patchset factors session's ordered samples queue,
and allows to limit the size of this queue.
v3 changes:
- rebased to latest tip/perf/core
- add comment for WARN in patch 8 (David)
- added ordered-events debug variable (David)
- renamed ordered_events_(get|put) to ordered_events_(new|delete)
- renamed struct ordered_events_queue to struct ordered_events
v2 changes:
- several small changes for review comments (Namhyung)
The report command queues events till any of following
conditions is reached:
- PERF_RECORD_FINISHED_ROUND event is processed
- end of the file is reached
Any of above conditions will force the queue to flush some
events while keeping all allocated memory for next events.
If PERF_RECORD_FINISHED_ROUND is missing the queue will
allocate memory for every single event in the perf.data.
This could lead to enormous memory consuption and speed
degradation of report command for huge perf.data files.
With the quue allocation limit of 100 MB, I've got around
15% speedup on reporting of ~10GB perf.data file.
current code:
Performance counter stats for './perf.old report --stdio -i perf-test.data' (3 runs):
621,685,704,665 cycles ( +- 0.52% )
873,397,467,969 instructions ( +- 0.00% )
286.133268732 seconds time elapsed ( +- 1.13% )
with patches:
Performance counter stats for './perf report --stdio -i perf-test.data' (3 runs):
603,933,987,185 cycles ( +- 0.45% )
869,139,445,070 instructions ( +- 0.00% )
245.337510637 seconds time elapsed ( +- 0.49% )
The speed up seems to be mainly in less cycles spent in servicing
page faults:
current code:
4.44% 0.01% perf.old [kernel.kallsyms] [k] page_fault
with patches:
1.45% 0.00% perf [kernel.kallsyms] [k] page_fault
current code (faults event):
6,643,807 faults ( +- 0.36% )
with patches (faults event):
2,214,756 faults ( +- 3.03% )
Also now we have one of our big memory spender under control
and the ordered events queue code is put in separated object
with clear interface ready to be used by another command
like script.
Also reachable in here:
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
perf/core_ordered_events
thanks,
jirka
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc: David Ahern <dsahern@...il.com>
Cc: Frederic Weisbecker <fweisbec@...il.com>
Cc: Ingo Molnar <mingo@...nel.org>
Cc: Jean Pihet <jean.pihet@...aro.org>
Cc: Namhyung Kim <namhyung@...nel.org>
Cc: Paul Mackerras <paulus@...ba.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Signed-off-by: Jiri Olsa <jolsa@...nel.org>
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists