Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753509AbcCWWtw (ORCPT <rfc822;w@1wt.eu>);
	Wed, 23 Mar 2016 18:49:52 -0400
Received: from mga11.intel.com ([192.55.52.93]:51814 "EHLO mga11.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751458AbcCWWtv (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 23 Mar 2016 18:49:51 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,383,1455004800"; 
   d="scan'208";a="674642802"
Date: Wed, 23 Mar 2016 15:49:58 -0700 (PDT)
From: Vikas Shivappa <vikas.shivappa@linux.intel.com>
X-X-Sender: vikas@vshiva-Udesk
To: Matt Fleming <matt@codeblueprint.co.uk>
cc: Vikas Shivappa <vikas.shivappa@linux.intel.com>, hpa@zytor.com,
        eranian@google.com, linux-kernel@vger.kernel.org, tony.luck@intel.com,
        brgerst@gmail.com, peterz@infradead.org, bp@alien8.de,
        tglx@linutronix.de, dsahern@gmail.com, dvlasenk@redhat.com,
        jolsa@redhat.com, luto@amacapital.net, mingo@kernel.org,
        acme@redhat.com, torvalds@linux-foundation.org, namhyung@kernel.org,
        vincent.weaver@maine.edu, alexander.shishkin@linux.intel.com,
        linux-tip-commits@vger.kernel.org
Subject: Re: [tip:perf/urgent] perf/x86/cqm: Fix CQM handling of grouping
 events into a cache_group
In-Reply-To: <20160323201438.GH11676@codeblueprint.co.uk>
Message-ID: <alpine.DEB.2.10.1603231501140.25124@vshiva-Udesk>
References: <1457652732-4499-2-git-send-email-vikas.shivappa@linux.intel.com> <tip-a223c1c7ab4cc64537dc4b911f760d851683768a@git.kernel.org> <20160321145741.GC11676@codeblueprint.co.uk> <alpine.DEB.2.10.1603211109210.25124@vshiva-Udesk>
 <20160323201438.GH11676@codeblueprint.co.uk>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1414
Lines: 39



On Wed, 23 Mar 2016, Matt Fleming wrote:

> On Mon, 21 Mar, at 11:14:37AM, Vikas Shivappa wrote:
>>
>>
>> Before MBM , the below condition was never hit because we had only one event ?
>>
>> -       if (a->hw.target == b->hw.target)
>> +       if (a->hw.target == b->hw.target) {
>> +               b->hw.is_group_event = true;
>>
>> We are trying to address this for cases where different MBM(local or total)
>> and cqm events are grouped into one RMID.
>
> I can't test these changes, so I'm only working from memory, but I
> seem to recall that this condition is hit if monitoring simultaneously
> from two invocations of perf. It's also possible to have pid/tid
> groups overlapping, and that needs to be handled.

Each task in a multithreaded process has an event. So it gets a different RMID. 
If two perf instances invoke 
the same pid then both of the instances expect to see the counters so its 
reported to both of them.

>
>> Which is the case which led to duplicate values ?
>
> Good question. Try monitoring a multithread process with these changes
> and see if you get duplicate values reported.

perf starts an event for each thread even when you give -p <process id>  a 
process which has multiple threads).
So it sends the pid of each thread to monitor and they get all seperate RMIDs. 
This should apply to the groups overlapping as well as this is dealing with only 
the perf task events..

>