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 S1752531AbdATOoc (ORCPT <rfc822;w@1wt.eu>);
        Fri, 20 Jan 2017 09:44:32 -0500
Received: from Galois.linutronix.de ([146.0.238.70]:60901 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751962AbdATOoa (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 20 Jan 2017 09:44:30 -0500
Date: Fri, 20 Jan 2017 14:28:55 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: David Carrillo-Cisneros <davidcc@google.com>
cc: 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>,
        Peter Zijlstra <peterz@infradead.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
In-Reply-To: <CALcN6mhcoTk7JT3ixSLCOHFVq4v0_j4wfHW4onhDYupOXfpGJA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1701201053350.3602@nanos>
References: <alpine.DEB.2.20.1701180905130.3464@nanos> <1484879563-29977-1-git-send-email-vikas.shivappa@linux.intel.com> <CALcN6mhcoTk7JT3ixSLCOHFVq4v0_j4wfHW4onhDYupOXfpGJA@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
> 
> If resctrl groups could lift the restriction of one resctl per CLOSID,
> then the user can create many resctrl in the way perf cgroups are
> created now. The advantage is that there wont be cgroup hierarchy!
> making things much simpler. Also no need to optimize perf event
> context switch to make llc_occupancy work.

So if I understand you correctly, then you want a mechanism to have groups
of entities (tasks, cpus) and associate them to a particular resource
control group.

So they share the CLOSID of the control group and each entity group can
have its own RMID.

Now you want to be able to move the entity groups around between control
groups without losing the RMID associated to the entity group.

So the whole picture would look like this:

rdt ->  CTRLGRP -> CLOSID

mon ->  MONGRP  -> RMID
   
And you want to move MONGRP from one CTRLGRP to another.

Can you please write up in a abstract way what the design requirements are
that you need. So far we are talking about implementation details and
unspecfied wishlists, but what we really need is an abstract requirement.

Thanks,

	tglx