From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764187AbdDSOPY (ORCPT ); Wed, 19 Apr 2017 10:15:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48564 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1764172AbdDSOPU (ORCPT ); Wed, 19 Apr 2017 10:15:20 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CA39F80495 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jolsa@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com CA39F80495 Date: Wed, 19 Apr 2017 16:15:16 +0200 From: Jiri Olsa To: Jin Yao Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org, ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v5 4/7] perf report: Refactor the branch info printing code Message-ID: <20170419141516.GB19643@krava> References: <1492616894-3635-1-git-send-email-yao.jin@linux.intel.com> <1492616894-3635-5-git-send-email-yao.jin@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1492616894-3635-5-git-send-email-yao.jin@linux.intel.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 19 Apr 2017 14:15:20 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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