On 7/24/2020 12:43 PM, pet...@infradead.org wrote:
On Fri, Jul 24, 2020 at 04:59:34PM +0200, Peter Zijlstra wrote:
On Fri, Jul 24, 2020 at 07:46:32AM -0700, Andi Kleen wrote:
Something that seems to 'work' is:
'{cycles,cpu/instructions,period=50000/}', so maybe you can make the
group modifier :S use any sampling event if there is one, and otherwise
designate the leader.
Then you can write things like:
'{slots, metric1, metric2, cpu/cycles,freq=50000/}:S'
and then since cycles is specified as a sampling event, it will use
that.
Okay possible, but it makes things more complicated
for the user to understand and requires special documentation.
Hopefully it's worth it the internal simplification.
You already require special documentation for this metrics stuff. We
already need to state that SLOTS cannot be a sampling event, so you
already need to pay attention to this anyway.
A shortcut could be a :s event modifier, then you can write:
'{slots, metric1, metric2, cycles:s}:S'
and have the tool select the :s tagged one.
It looks like PT encountered a similar issue as us.
They use the 2nd event of the group as the
"leader". I think we can simply extend the function to check the slots
event in perf tool.
https://lore.kernel.org/lkml/20200401101613.6201-17-adrian.hun...@intel.com/
Having slots as leader also would allow doing something like
FORMAT_METRIC, where we return sibling/leader in some fashion.
That also makes sense for instructions, because, IIRC,
instructions/slots is the better IPC.
And we should probably consider FORMAT_RESET.
What's FORMAT_RESET for?
Thanks,
Kan