From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1759216AbcIHSQD (ORCPT <rfc822;w@1wt.eu>);
        Thu, 8 Sep 2016 14:16:03 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:53832 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752524AbcIHSQB (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 8 Sep 2016 14:16:01 -0400
Date: Thu, 8 Sep 2016 20:15:52 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
        Ingo Molnar <mingo@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        Andi Kleen <andi@firstfloor.org>, Jiri Olsa <jolsa@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        David Carrillo-Cisneros <davidcc@google.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Namhyung Kim <namhyung@kernel.org>, "Liang, Kan" <kan.liang@intel.com>,
        Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 7/7] perf/annotate: Add branch stack / basic block
 information
Message-ID: <20160908181552.GW10153@twins.programming.kicks-ass.net>
References: <20160708133059.031522978@infradead.org>
 <20160708134113.718203556@infradead.org>
 <20160708145555.GB17466@gmail.com>
 <20160708162733.GJ30909@twins.programming.kicks-ass.net>
 <20160708163632.GK30927@twins.programming.kicks-ass.net>
 <20160908161857.GA4801@kernel.org>
 <CABPqkBRuRtZXNN2Mhck0sph-10-k7w31ZhaUO_fbXHfcwfyAzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABPqkBRuRtZXNN2Mhck0sph-10-k7w31ZhaUO_fbXHfcwfyAzQ@mail.gmail.com>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Sep 08, 2016 at 09:43:53AM -0700, Stephane Eranian wrote:

> I like the idea and yes, branch stack can be used for this, but I have
> a hard time understanding the colored output.

> What is the explanation for the color changes?

In general, or the changes acme made? I can only answer the first.

For code: NORMAL <1%, BLUE otherwise, quickly shows you the code in a
function that's not ran at all. This quickly eliminated a big chunk of
the function I was looking at at the time, since the benchmark in
question simply didn't touch most of it.

For address: NORMAL <1%, RED > 75%, MAGENTA otherwise. Quickly shows the
hottest blocks in a function. The 75% is a random number otherwise. Not
sure if we can do better.

> How do I interpret the percentages in the comments of the assembly:
> -54.50% (p: 42%)

-54.50% is 54.40% of the coverage is leaving here, aka 54.40% take this
branch. p: 42% mean the branch is predicted 42% of the time.

Similarly, +50.46% is a branch target and means that of all the times
this instruction gets executed, 50.46% of those joined at this
instruction.

> Why not have dedicated columns before the assembly with proper column headers?

I found it too noisy, you only want to annotate branch instructions and
branch targets. Adding columns just adds a whole heap of whitespace
(wasted screen-estate) on the left.

Something I did want to look at was attempting to align the # comments,
but I never did bother.

But to each their own I suppose.