[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170208101135.GW6515@twins.programming.kicks-ass.net>
Date: Wed, 8 Feb 2017 11:11:35 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: David Carrillo-Cisneros <davidcc@...gle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
Vikas Shivappa <vikas.shivappa@...el.com>,
Stephane Eranian <eranian@...gle.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>, hpa@...or.com,
Ingo Molnar <mingo@...nel.org>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
"Luck, Tony" <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>, andi.kleen@...el.com,
"H. Peter Anvin" <h.peter.anvin@...el.com>
Subject: Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes
On Fri, Jan 20, 2017 at 12:11:53PM -0800, David Carrillo-Cisneros wrote:
> Implementation ideas:
>
> First idea is to expose one monitoring file per resource in a CTRLGRP,
> so the list of CTRLGRP's files would be: schemata, tasks, cpus,
> monitor_l3_0, monitor_l3_1, ...
>
> the monitor_<resource_id> file descriptor is passed to perf_event_open
> in the way cgroup file descriptors are passed now. All events to the
> same (CTRLGRP,resource_id) share RMID.
>
> The RMID allocation part can either be handled by RDT Allocation or by
> the RDT Monitoring PMU. Either ways, the existence of PMU's
> perf_events allocates/releases the RMID.
So I've had complaints about exactly that behaviour. Someone wanted
RMIDs assigned (and start measuring) the moment the grouping got
created/tasks started running etc..
So I think the design should also explicitly state how this is supposed
to be handled and not left as an implementation detail.
Powered by blists - more mailing lists