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 S1751101AbdBCRwW (ORCPT <rfc822;w@1wt.eu>);
        Fri, 3 Feb 2017 12:52:22 -0500
Received: from mga07.intel.com ([134.134.136.100]:40605 "EHLO mga07.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750937AbdBCRwV (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 3 Feb 2017 12:52:21 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,329,1477983600"; 
   d="scan'208";a="816743552"
Date: Fri, 3 Feb 2017 09:52:20 -0800
From: "Luck, Tony" <tony.luck@intel.com>
To: David Carrillo-Cisneros <davidcc@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>,
        "Shivappa, Vikas" <vikas.shivappa@intel.com>,
        Stephane Eranian <eranian@google.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
        "hpa@zytor.com" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        "Yu, Fenghua" <fenghua.yu@intel.com>,
        "Kleen, Andi" <andi.kleen@intel.com>,
        "Anvin, H Peter" <h.peter.anvin@intel.com>
Subject: Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes
Message-ID: <20170203175220.GA15630@intel.com>
References: <alpine.DEB.2.20.1701201053350.3602@nanos>
 <CALcN6mjjAhinhKW_PtQhBNA6N3wLL=BkrrJ3oX5++M_cQuF-uQ@mail.gmail.com>
 <alpine.DEB.2.20.1701231013360.3836@nanos>
 <3908561D78D1C84285E8C5FCA982C28F3A2A8947@ORSMSX114.amr.corp.intel.com>
 <CALcN6mjYAaF2=2S_-afZz-iNM8NcoLEXFo5Mh30WJk=quaUTfA@mail.gmail.com>
 <3908561D78D1C84285E8C5FCA982C28F3A2A9CC7@ORSMSX114.amr.corp.intel.com>
 <CALcN6mhLz3B6w+o2ZFtG5PV1M-5Uz7o=34DN2U8uEW6xco+KSQ@mail.gmail.com>
 <20170202234100.GA17145@intel.com>
 <CALcN6mhh7ST0fs2K+dcCZBcGdYKyXD+Gvn7zhTbqH1Zn_hrp2Q@mail.gmail.com>
 <CALcN6mjbapHMjDttiq9A2kNfrOes55tFVoVWO9EMaPZuy+GwPA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALcN6mjbapHMjDttiq9A2kNfrOes55tFVoVWO9EMaPZuy+GwPA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Feb 02, 2017 at 06:14:05PM -0800, David Carrillo-Cisneros wrote:
> If we tie allocation groups and monitoring groups, we are tying the
> meaning of CPUs and we'll have to choose between the CAT meaning or
> the perf meaning.
> 
> Let's allow semantics that will allow perf like monitoring to
> eventually work, even if its not immediately supported.

Would it work to make monitor groups be "task list only" or "cpu mask only"
(unlike control groups that allow mixing).

Then the intel_rdt_sched_in() code could pick the RMID in ways that
give you the perf(1) meaning. I.e. if you create a monitor group and assign
some CPUs to it, then we will always load the RMID for that monitor group
when running on those cpus, regardless of what group(s) the current process
belongs to.  But if you didn't create any cpu-only monitor groups, then we'd
assign RMID using same rules as CLOSID (so measurements from a control group
would track allocation policies).

We are already planning that creating monitor only groups will change
what is reported in the control group (e.g. you pull some tasks out of
the control group to monitor them separately, so the control group only
reports the tasks that you didn't move out for monitoring).

-Tony