Re: [PATCH 08/11] perf/x86/intel: Add Intel Cache QoS Monitoring support

From: Peter Zijlstra
Date: Wed Oct 08 2014 - 16:51:26 EST


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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/