Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753860AbdCHR6d (ORCPT ); Wed, 8 Mar 2017 12:58:33 -0500 Received: from mail-ua0-f171.google.com ([209.85.217.171]:35189 "EHLO mail-ua0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750770AbdCHR6c (ORCPT ); Wed, 8 Mar 2017 12:58:32 -0500 MIME-Version: 1.0 In-Reply-To: References: <1488908964-30261-1-git-send-email-vikas.shivappa@linux.intel.com> <3908561D78D1C84285E8C5FCA982C28F6120F0A9@ORSMSX113.amr.corp.intel.com> From: David Carrillo-Cisneros Date: Wed, 8 Mar 2017 09:58:26 -0800 Message-ID: Subject: Re: [PATCH 1/1] x86/cqm: Cqm requirements To: Thomas Gleixner Cc: Stephane Eranian , "Luck, Tony" , Vikas Shivappa , "Shivappa, Vikas" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "hpa@zytor.com" , "mingo@kernel.org" , "peterz@infradead.org" , "Shankar, Ravi V" , "Yu, Fenghua" , "Kleen, Andi" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1633 Lines: 48 On Wed, Mar 8, 2017 at 12:30 AM, Thomas Gleixner wrote: > Stephane, > > On Tue, 7 Mar 2017, Stephane Eranian wrote: >> On Tue, Mar 7, 2017 at 12:04 PM, Luck, Tony wrote: >> >> That's all nice and good, but I still have no coherent explanation why >> >> measuring across allocation domains makes sense. >> > >> > Is this in reaction to this one? >> > >> >>> 5) Put multiple threads into a single measurement group >> > >> > If we fix it to say "threads from the same CAT group" does it fix things? >> > >> Inside a CAT partition, there may be multiple tasks split into different >> cgroups. We need the ability to monitor groups of tasks individually >> within that CAT partition. I think this is what this bullet is about. > > I completely understand that. That's fine and I never debated that one, but > the requirements list is too vague about what you want to measure. > >> >>> 5) Put multiple threads into a single measurement group > > That can be: > > A) threads within a CAT group > > B) threads which belong to different CAT groups > > A) is fine. B) does not make any sense to me It's A). As Tony suggested in a previous email, we can rephrase it to: 5) Put a subset of threads from the same CAT group into a single measurement group. > > Same applies for per CPU measurements. For CPU measurements. We need perf-like CPU filtering to support tools that perform low overhead monitoring by polling CPU events. These tools approximate per-cgroup/task events by reconciling CPU events with logs of what job run when in what CPU. > > Thanks, > > tglx