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 S1751477AbdBBBTW (ORCPT <rfc822;w@1wt.eu>);
        Wed, 1 Feb 2017 20:19:22 -0500
Received: from one.firstfloor.org ([193.170.194.197]:50783 "EHLO
        one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751409AbdBBBTV (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 1 Feb 2017 20:19:21 -0500
Date: Wed, 1 Feb 2017 17:19:18 -0800
From: Andi Kleen <andi@firstfloor.org>
To: David Carrillo-Cisneros <davidcc@google.com>
Cc: Andi Kleen <andi@firstfloor.org>, "Luck, Tony" <tony.luck@intel.com>,
        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: <20170202011918.GC26852@two.firstfloor.org>
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>
 <alpine.DEB.2.20.1701231013360.3836@nanos>
 <3908561D78D1C84285E8C5FCA982C28F3A2A8947@ORSMSX114.amr.corp.intel.com>
 <87inotjupi.fsf@firstfloor.org>
 <CALcN6mgoZ7i-Lcu3jaCn-j4P0tWTMVui_BopSW-Ha6qmS_5A3g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALcN6mgoZ7i-Lcu3jaCn-j4P0tWTMVui_BopSW-Ha6qmS_5A3g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > I'm not sure this is a real requirement. It's just an optimization,
> > right? If you can assign policies to threads, you can implicitly set it
> > per CPU through affinity (or the other way around).
> 
> That's difficult when distinct users/systems do monitoring and system
> management.  What if the cluster manager decides to change affinity
> for a task after the monitoring service has initiated monitoring a CPU
> in the way you describe?

Why would you want to monitor a CPU if you don't know what it is
running?  The results would be meaningless. So you really want
to integrate those two services.

> 
> > The only benefit would be possibly less context switch overhead,
> > but if all the thread (including idle) assigned to a CPU have the
> > same policy it would have the same results.
> 
> I think another of the reasons for the CPU monitoring requirement is
> to monitor interruptions in CPUs running the idle thread. In CAT,

idle threads are just threads, so they could be just exposed
to perf (e.g. combination of pid 0 + cpu filter)


> Also, if perf's like monitoring is supported, it'd allow something like
> 
>   perf stat -e LLC-load,LLC-prefetches,intel_cqm/total_bytes -C 2

This would work without a special API.

-Andi