We currently use the scale 0.23nJ for all RAPL perf event values, but the RAPL perf event scale for each domain (PKG, CORES, DRAM, etc) should be determined by the corresponding sysfs files. The scale value should be present in /sys/bus/event_source/devices/power/events/energy-<domain>.scale. For example:

cat /sys/bus/event_source/devices/power/events/energy-pkg.scale
2.3283064365386962890625e-10

Which files are we looking at? Any specific preferences on how this is to be solved?

(In reply to Razvan Cojocaru from comment #1)

Which files are we looking at? Any specific preferences on how this is to be solved?

The class is defined in PowerCounters-linux.cpp. We currently use a constant PERF_EVENT_SCALE_NANOJOULES to scale the value we get from the perf event file descriptor here. Instead of relying on the constant we could read the scale value from /sys/bus/event_source/devices/power/events/energy-pkg.scale and use that like we do for the event type here.

(In reply to Dan Robertson (:dlrobertson) from comment #2)

The class is defined in PowerCounters-linux.cpp. We currently use a constant PERF_EVENT_SCALE_NANOJOULES to scale the value we get from the perf event file descriptor here. Instead of relying on the constant we could read the scale value from /sys/bus/event_source/devices/power/events/energy-pkg.scale and use that like we do for the event type here.

Got it, thanks! Do we prefer fopen() to std::fstream (as per here)?

(In reply to Razvan Cojocaru from comment #3)

Got it, thanks! Do we prefer fopen() to std::fstream (as per here)?

Great question! It seems that we do use fstream elsewhere in tools/profiler/core. Whatever you're most comfortable with will work. I totally forgot about std::fstream in the initial implementation, and I probably should have used it... Old habits are hard to kick :p

(In reply to Dan Robertson (:dlrobertson) from comment #4)

(In reply to Razvan Cojocaru from comment #3)

Got it, thanks! Do we prefer fopen() to std::fstream (as per here)?

Great question! It seems that we do use fstream elsewhere in tools/profiler/core. Whatever you're most comfortable with will work. I totally forgot about std::fstream in the initial implementation, and I probably should have used it... Old habits are hard to kick :p

Thanks for the quick reply! I have no problem with either approach, was just curious. :) I just thought maybe that binary wasn't meant to link with libstdc++ or something of that sort.

I'll cook up a patch in the next couple of days.

https://hg.mozilla.org/mozilla-central/rev/b4d604939fe8