Messages in this thread | | | From | David Carrillo-Cisneros <> | Date | Thu, 2 Feb 2017 12:22:42 -0800 | Subject | Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes |
| |
On Thu, Feb 2, 2017 at 11:33 AM, Luck, Tony <tony.luck@intel.com> wrote: >>> Nice to have: >>> 1) Readout using "perf(1)" [subset of modes that make sense ... tying monitoring >>> to resctrl file system will make most command line usage of perf(1) close to impossible. >> >> >> We discussed this offline and I still disagree that it is close to >> impossible to use perf and perf_event_open. In fact, I think it's very >> simple : > > Maybe s/most/many/ ? > > The issue here is that we are going to define which tasks and cpus are being > monitored *outside* of the perf command. So usage like: > > # perf stat -I 1000 -e intel_cqm/llc_occupancy {command} > > are completely out of scope ... we aren't planning to change the perf(1) > command to know about creating a CQM monitor group, assigning the > PID of {command} to it, and then report on llc_occupancy. > > So perf(1) usage is only going to support modes where it attaches to some > monitor group that was previously established. The "-C 2" option to monitor > CPU 2 is certainly plausible ... assuming you set up a monitor group to track > what is happening on CPU 2 ... I just don't know how perf(1) would know the > name of that group.
There is no need to change perf(1) to support # perf stat -I 1000 -e intel_cqm/llc_occupancy {command}
the PMU can work with resctrl to provide the support through perf_event_open, with the advantage that tools other than perf could also use it.
I'd argue is more stable and has less corner cases if the task_mongroups get extra RMIDs for the task events attached to them than having userspace tools create and destroy groups and move tasks behind the scenes.
I provided implementation details on the write-up I shared offline on Monday. If "easy monitoring" of stand-alone task becomes a requirement, we can dig on the pros and cons of implementing in kernel vs user space.
> > Vikas is pushing for "-R rdtgroup" ... though our offline discussions included > overloading "-g" and have perf(1) pick appropriately from cgroups or rdtgroups > depending on event type.
I see it more like generalizing the -G option to represent a task group that can be a cgroup or a PMU specific one.
Currently the perf(1) simply translates the argument of the -G option into a file descriptor. My idea doesn't change that, just makes perf tool to look for a "task_group_root" file in the PMU folder and use it to find as base path for the file descriptor. If a PMU doesnt have such file, then perf(1) uses the perf cgroup mounting point, as it does now. That makes for a very simple implementation on the perf tool side.
| |