[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170117123132.GB6485@twins.programming.kicks-ass.net>
Date: Tue, 17 Jan 2017 13:31:32 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
vikas.shivappa@...el.com, davidcc@...gle.com, eranian@...gle.com,
linux-kernel@...r.kernel.org, x86@...nel.org, hpa@...or.com,
mingo@...nel.org, ravi.v.shankar@...el.com, tony.luck@...el.com,
fenghua.yu@...el.com, andi.kleen@...el.com, h.peter.anvin@...el.com
Subject: Re: [PATCH 05/12] x86/cqm,perf/core: Cgroup support prepare
On Tue, Jan 17, 2017 at 01:11:50PM +0100, Thomas Gleixner wrote:
> On Fri, 6 Jan 2017, Vikas Shivappa wrote:
>
> > From: David Carrillo-Cisneros <davidcc@...gle.com>
> >
> > cgroup hierarchy monitoring is not supported currently. This patch
> > builds all the necessary datastructures, cgroup APIs like alloc, free
> > etc and necessary quirks for supporting cgroup hierarchy monitoring in
> > later patches.
> >
> > - Introduce a architecture specific data structure arch_info in
> > perf_cgroup to keep track of RMIDs and cgroup hierarchical monitoring.
> > - perf sched_in calls all the cgroup ancestors when a cgroup is
> > scheduled in. This will not work with cqm as we have a common per pkg
> > rmid associated with one task and hence cannot write different RMIds
> > into the MSR for each event. cqm driver enables a flag
> > PERF_EV_CGROUP_NO_RECURSION which indicates the perf to not call all
> > ancestor cgroups for each event and let the driver handle the hierarchy
> > monitoring for cgroup.
> > - Introduce event_terminate as event_destroy is called after cgrp is
> > disassociated from the event to support rmid handling of the cgroup.
> > This helps cqm clean up the cqm specific arch_info.
> > - Add the cgroup APIs for alloc,free,attach and can_attach
> >
> > The above framework will be used to build different cgroup features in
> > later patches.
>
> That's not a framework. It's a hodgepodge of core and x86 specific changes.
Trainwreck comes to mind. It completely fails to describe semantics of
the hacks and how they would preserve the cgroup invariants.
Powered by blists - more mailing lists