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 S1751479AbdARQ4j (ORCPT <rfc822;w@1wt.eu>);
        Wed, 18 Jan 2017 11:56:39 -0500
Received: from mx1.redhat.com ([209.132.183.28]:40026 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751345AbdARQ4g (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 18 Jan 2017 11:56:36 -0500
Date: Wed, 18 Jan 2017 17:56:31 +0100
From: Jiri Olsa <jolsa@redhat.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Andi Kleen <andi@firstfloor.org>, acme@kernel.org, jolsa@kernel.org,
        linux-kernel@vger.kernel.org, mingo@kernel.org
Subject: Re: [PATCH 07/11] perf, tools: Collapse identically named events in
 perf stat
Message-ID: <20170118165631.GA17613@krava>
References: <20170103150833.6694-1-andi@firstfloor.org>
 <20170103150833.6694-8-andi@firstfloor.org>
 <20170118124446.GE11946@krava>
 <20170118163126.GE5460@tassilo.jf.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170118163126.GE5460@tassilo.jf.intel.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 18 Jan 2017 16:56:35 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jan 18, 2017 at 08:31:26AM -0800, Andi Kleen wrote:
> > > % perf stat  -a  -e unc_c_llc_lookup.any sleep 1
> > > 
> > >  Performance counter stats for 'system wide':
> > > 
> > >          2,685,120 Bytes unc_c_llc_lookup.any
> > > 
> > >        1.002648032 seconds time elapsed
> > 
> > 
> > if one of them is not supported, we get wrong output:
> 
> 
> I would argue the output is not incorrect, after all it is not supported
> if something is missing. 
> 
> Imagine this is run with an interval:
> 
> If we changed the number of output lines based on some dynamic scheduling
> condition this could confuse post processing scripts or users. Some output
> records would be completely different than others. So marking everything
> merged <not supported> in these cases is better and more consistent.
> 
> It is also difficult to change and should be a rare condition.

will it always show 'not supported', as I haven't found this in the
changelog I guess you did not know about this behaviour?

could you also please document it somewhere

jirka