Issue 216 alder lake support #217
Conversation
There was a problem hiding this comment.
One of the currently rather ugly things is that I'm creating a metric_class for every cpu (As every cpu can possibly have completely different metric_members) which looks like this in Vampir:
I think you're overengineering here a bit. Shouldn't all events from the cpu PMU be available
on all cpus. And events from cpu_core or cpu_atom only be available on their distinct groups of cpus? Hence, there is either one metric_class for all cpus, or two metric_classes with completely distinct CPU groups, which might be a nightmare to track, but should be possible nonetheless.
| @@ -119,46 +119,51 @@ Trace::Trace() | |||
| registry_.create<otf2::definition::system_tree_node_domain>( | |||
| system_tree_root_node_, otf2::common::system_tree_node_domain::shared_memory); | |||
| const auto& sys = Topology::instance(); | |||
| for (auto& package : sys.packages()) | |||
| for (auto& cpu : sys.cpus()) | |||
There was a problem hiding this comment.
This is where not having the relations between package->core->cpu really hurts, as you constantly need to check whether things are there, making the code hard to understand in comparison. I'm not sure if I like that.
cvonelm
force-pushed
the
issue-216-alder-lake-support
branch
from
c34fd44
to
fdd2bba
Compare
With Alder Lake, the Linux kernel gained an architecture, where different cores can have different sets of events available. This commit makes lo2s respect the /sys/bus/event_source/devices/[pmu]/cpus file, which specifies which CPUs support that PMU and subsequently only opens the events on the CPUs that support it.
cvonelm
force-pushed
the
issue-216-alder-lake-support
branch
from
fdd2bba
to
af5596a
Compare
This PR adds lo2s support for the heterogenous Alder Lake architecture.
Sadly, this did not make topdown available as simple perf events as I thought, but all other events work now.
this archive contains a simple example trace recorded with
lo2s -A -E cpu_core/cache-misses -E cpu_atom/cache-missesOne of the currently rather ugly things is that I'm creating a
metric_classfor every cpu (As every cpu can possibly have completely differentmetric_members) which looks like this in Vampir:A fix would be using the same metric_class and writing 0 to events not supported on that core. I think this is a hack we have to take, but I would like prior input. Problems with this approach is that tracking which events are supported and which arent might be costly to do during measurements.
This fixes #216