On Wed, Mar 8, 2017 at 12:30 AM, Thomas Gleixner <t...@linutronix.de> wrote: > Stephane, > > On Tue, 7 Mar 2017, Stephane Eranian wrote: >> On Tue, Mar 7, 2017 at 12:04 PM, Luck, Tony <tony.l...@intel.com> 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