linux-kernel - [PATCHv2] perf tools: Separate progress bar update when processing events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Sep 2013 11:14:50 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	David Ahern <dsahern@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Namhyung Kim <namhyung@...nel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: [PATCHv2] perf tools: Separate progress bar update when processing
 events

On Wed, Sep 04, 2013 at 10:47:22AM -0600, David Ahern wrote:
> On 9/4/13 10:27 AM, Jiri Olsa wrote:

SNIP

> >index 1fc0c62..4df449c 100644
> >--- a/tools/perf/util/session.c
> >+++ b/tools/perf/util/session.c
> >@@ -495,7 +495,7 @@ static int perf_session_deliver_event(struct perf_session *session,
> >  				      u64 file_offset);
> >
> >  static int flush_sample_queue(struct perf_session *s,
> >-		       struct perf_tool *tool)
> >+		       struct perf_tool *tool, bool final)
> 
> Why not base it on next_flush = ULLONG_MAX? Then you don't need the
> extra arg.

ok, v2 attached

thanks,
jirka

---
Currently when processing events in __perf_session__process_events
function we we update progress based on the file_size. During the
same processing we update progress bar from within flush_sample_queue
which is based on number of samples count.

Having 2 different based updates is causing the progress bar to
jump heavily back and forth giving not much usefull info.

Fixing this byt keeping only __perf_session__process_events
based progress bar update. And turning on flush_sample_queue
progress bar update only for final flushing.

This reduces the number of time the progress bar update
function is called and it significantly reduces the loading
time for TUI, where the progress bar update takes quite a lot
of time.

Signed-off-by: Jiri Olsa <jolsa@...hat.com>
Cc: Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@...il.com>
Cc: Ingo Molnar <mingo@...e.hu>
Cc: Namhyung Kim <namhyung@...nel.org>
Cc: Paul Mackerras <paulus@...ba.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
Cc: David Ahern <dsahern@...il.com>
---
 tools/perf/util/session.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 1fc0c62..476caa1 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -504,6 +504,7 @@ static int flush_sample_queue(struct perf_session *s,
 	u64 limit = os->next_flush;
 	u64 last_ts = os->last_sample ? os->last_sample->timestamp : 0ULL;
 	unsigned idx = 0, progress_next = os->nr_samples / 16;
+	bool show_progress = limit == ULLONG_MAX;
 	int ret;
 
 	if (!tool->ordered_samples || !limit)
@@ -526,7 +527,7 @@ static int flush_sample_queue(struct perf_session *s,
 		os->last_flush = iter->timestamp;
 		list_del(&iter->list);
 		list_add(&iter->list, &os->sample_cache);
-		if (++idx >= progress_next) {
+		if (show_progress && (++idx >= progress_next)) {
 			progress_next += os->nr_samples / 16;
 			ui_progress__update(idx, os->nr_samples,
 					    "Processing time ordered events...");
-- 
1.7.11.7

--
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/