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 S933060AbdCGUMN (ORCPT <rfc822;w@1wt.eu>);
        Tue, 7 Mar 2017 15:12:13 -0500
Received: from Galois.linutronix.de ([146.0.238.70]:43657 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754790AbdCGUML (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 7 Mar 2017 15:12:11 -0500
Date: Tue, 7 Mar 2017 20:31:43 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Vikas Shivappa <vikas.shivappa@linux.intel.com>
cc: vikas.shivappa@intel.com, tony.luck@intel.com, x86@kernel.org,
        linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org,
        peterz@infradead.org, ravi.v.shankar@intel.com, fenghua.yu@intel.com,
        andi.kleen@intel.com, davidcc@google.com, eranian@google.com
Subject: Re: [PATCH 1/1] x86/cqm: Cqm requirements
In-Reply-To: <1488908964-30261-1-git-send-email-vikas.shivappa@linux.intel.com>
Message-ID: <alpine.DEB.2.20.1703072011080.4299@nanos>
References: <1488908964-30261-1-git-send-email-vikas.shivappa@linux.intel.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 Tue, 7 Mar 2017, Vikas Shivappa wrote:

> Sending the cqm requirements as per Thomas comments in the previous
> verson of cqm patch series -
> https://marc.info/?l=linux-kernel&m=148374167726502
> 
> This is modified version of requirements sent by Tony in the same
> thread with inputs from David and Stephan.
> 
> Reviewed-by: Tony Luck<tony.luck@intel.com>
> Reviewed-by: David Carrillo-Cisneros <davidcc@google.com>
> Reviewed-by: Yu Fenghua <fenghua.yu@intel.com>
> Reviewed-by: Stephane Eranian <eranian@google.com>
> Signed-off-by: Vikas Shivappa <vikas.shivappa@linux.intel.com>

That's all nice and good, but I still have no coherent explanation why
measuring across allocation domains makes sense.

Repeating this requirement w/o explanation does not get us anywhere.

For the record:

I can understand the use case for bandwidth, but that's a pretty trivial
act of summing it up in software, so there is no actual requirement to do
that with a seperate RMID.

For cache oocupancy it still does not make any sense unless there is some
magic voodoo I'm not aware of to decipher the meaning of those numbers.

Thanks,

	tglx