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 S1754195AbdBHLUW (ORCPT <rfc822;w@1wt.eu>);
        Wed, 8 Feb 2017 06:20:22 -0500
Received: from bombadil.infradead.org ([65.50.211.133]:47404 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752404AbdBHLUU (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 8 Feb 2017 06:20:20 -0500
Date: Wed, 8 Feb 2017 11:11:35 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: David Carrillo-Cisneros <davidcc@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>,
        Vikas Shivappa <vikas.shivappa@intel.com>,
        Stephane Eranian <eranian@google.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
        hpa@zytor.com, Ingo Molnar <mingo@kernel.org>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        "Luck, Tony" <tony.luck@intel.com>, Fenghua Yu <fenghua.yu@intel.com>,
        andi.kleen@intel.com, "H. Peter Anvin" <h.peter.anvin@intel.com>
Subject: Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes
Message-ID: <20170208101135.GW6515@twins.programming.kicks-ass.net>
References: <alpine.DEB.2.20.1701180905130.3464@nanos>
 <1484879563-29977-1-git-send-email-vikas.shivappa@linux.intel.com>
 <CALcN6mhcoTk7JT3ixSLCOHFVq4v0_j4wfHW4onhDYupOXfpGJA@mail.gmail.com>
 <alpine.DEB.2.20.1701201053350.3602@nanos>
 <CALcN6mjjAhinhKW_PtQhBNA6N3wLL=BkrrJ3oX5++M_cQuF-uQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALcN6mjjAhinhKW_PtQhBNA6N3wLL=BkrrJ3oX5++M_cQuF-uQ@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 Fri, Jan 20, 2017 at 12:11:53PM -0800, David Carrillo-Cisneros wrote:
> Implementation ideas:
> 
> First idea is to expose one monitoring file per resource in a CTRLGRP,
> so the list of CTRLGRP's files would be: schemata, tasks, cpus,
> monitor_l3_0, monitor_l3_1, ...
> 
> the monitor_<resource_id> file descriptor is passed to perf_event_open
> in the way cgroup file descriptors are passed now. All events to the
> same (CTRLGRP,resource_id) share RMID.
> 
> The RMID allocation part can either be handled by RDT Allocation or by
> the RDT Monitoring PMU. Either ways, the existence of PMU's
> perf_events allocates/releases the RMID.

So I've had complaints about exactly that behaviour. Someone wanted
RMIDs assigned (and start measuring) the moment the grouping got
created/tasks started running etc..

So I think the design should also explicitly state how this is supposed
to be handled and not left as an implementation detail.