Messages in this thread |  | | Date | Wed, 8 Oct 2014 22:51:14 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 08/11] perf/x86/intel: Add Intel Cache QoS Monitoring support |
| |
On Wed, Oct 08, 2014 at 04:47:04PM +0200, Peter Zijlstra wrote: > On Wed, Oct 08, 2014 at 01:15:35PM +0100, Matt Fleming wrote: > > I was having an interesting discussion with one of the teams using this > > stuff at Intel and they made the suggestion that when using, > > > > perf stat -p <pid> > > > > we should by default opt for sharing an RMID between all tasks in that > > thread group, rather that assigning a new RMID for each task, which is > > what we do currently. > > > > Right now, it's like the Oprah Winfrey of RMID assignment, "You get an > > RMID, and you get an RMID!" > > > > Which means we'll run out of RMIDs quicker, and enable the rotation code > > sooner. > > > > I'm wondering whether we should require that the user specify whether > > they want per-thread monitoring if using -p, via some perf tools event > > modifier, and make the record-per-thread-data scenario the exceptional > > case, rather than the default? > > Right so perf cannot do this. And I'm not sure that's fixable, it > depends a bit on how the cqm thing deals with inherited events, IFF it > can reuse RMIDs for inherited events we might be able to extend the > syscall to install 'inherited' events throughout the process group, > instead of just the one thread.
Right, so inherited events aren't going to work right for this. Look at patch 10, these events target a different task and will not match, so we'll not share RMIDs.
The only way to make this happen is stuff the process in a cgroup and measure the cgroup.
|  |