[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170419141516.GB19643@krava>
Date: Wed, 19 Apr 2017 16:15:16 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Jin Yao <yao.jin@...ux.intel.com>
Cc: acme@...nel.org, jolsa@...nel.org, peterz@...radead.org,
mingo@...hat.com, alexander.shishkin@...ux.intel.com,
Linux-kernel@...r.kernel.org, ak@...ux.intel.com,
kan.liang@...el.com, yao.jin@...el.com,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v5 4/7] perf report: Refactor the branch info printing
code
On Wed, Apr 19, 2017 at 11:48:11PM +0800, Jin Yao wrote:
SNIP
> +
> static int counts_str_build(char *bf, int bfsize,
> u64 branch_count, u64 predicted_count,
> u64 abort_count, u64 cycles_count,
> u64 iter_count, u64 samples_count)
> {
> - double predicted_percent = 0.0;
> - const char *null_str = "";
> - char iter_str[32];
> - char cycle_str[32];
> - char *istr, *cstr;
> u64 cycles;
> + int printed = 0, i = 0;
I like it, but it looks like the previous code displayed those
bits in another order.. I managed to catch this one:
1337c1337
< --0.53%--menu_select menu.c:218 (iterations:6 predicted:0.0%)
---
> --0.53%--menu_select menu.c:218 (predicted:0.0% iterations:6)
I think we better keep the current order, which seems
to be the goal of the original code as well
this function is perfect candidate for automated test ;-)
(something like we did in tests/kmod-path.c)
thanks,
jirka
Powered by blists - more mailing lists