You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR: Add support for having multiple groups of metric events all with different metric leaders (and possibly metric readout intervals)
This is something I've come across in the perf documentation recently.
Using a syntax like -e {cpu_core/cycles, cpu/branch_misses} {cpu_atom/cycles, cpu_atom/mem_stores} it is possible to specify two metric readout groups with two different metric leaders in perf.
One use case is the #213 issue. As the topdown metrics require a custom metric leader (as far as I understand it), which is most probably only useful with topdown events and not "normal" events like cpu_core/cache_misses one would currently have to choose between either measuring topdown events or measuring any other event.
The biggest downside would be, that this might be a breaking change to the lo2s command line options.
The text was updated successfully, but these errors were encountered:
I'm currently cleaning up the event reading code and I stumbled over this config check:
if (arguments.provided("metric-count") && !arguments.provided("metric-leader"))
{
Log::fatal() << "--metric-count can only be used in conjunction with a --metric-leader";
std::exit(EXIT_FAILURE);
}
if (arguments.provided("metric-frequency") && arguments.provided("metric-leader"))
{
Log::fatal() << "--metric-frequency can only be used with the default --metric-leader";
std::exit(EXIT_FAILURE);
}
TL;DR: Add support for having multiple groups of metric events all with different metric leaders (and possibly metric readout intervals)
This is something I've come across in the perf documentation recently.
Using a syntax like
-e {cpu_core/cycles, cpu/branch_misses} {cpu_atom/cycles, cpu_atom/mem_stores}
it is possible to specify two metric readout groups with two different metric leaders in perf.One use case is the #213 issue. As the topdown metrics require a custom metric leader (as far as I understand it), which is most probably only useful with topdown events and not "normal" events like
cpu_core/cache_misses
one would currently have to choose between either measuring topdown events or measuring any other event.The biggest downside would be, that this might be a breaking change to the lo2s command line options.
The text was updated successfully, but these errors were encountered: