683138 - Performance measurement utility doesn't work well on x86

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Mike Hommey [:glandium]]

I tried the following with scratchpad, in the browser environment (i.e. with chrome privs):
Components.utils.import("resource://gre/modules/PerfMeasurement.jsm");
pm = new PerfMeasurement(PerfMeasurement.ALL);
pm.start();
for (let i = 0; i < 100000000; i++) ;
pm.stop();
alert(pm.instructions);

It always returns 0 here, while pm.canMeasureSomething() is true.

Comment 1

[Mike Hommey [:glandium]]

It actually works if I replace PerfMeasurement.ALL with PerfMeasurement.INSTRUCTIONS or PerfMeasurement.INSTRUCTIONS | PerfMeasurement.CPU_CYCLES. I spotted with strace that 3 of the perf_event_open calls are failing, it may be related.

Comment 2

[Mike Hommey [:glandium]]

What happens is that I'm getting ENOSPC on perf_event_open for PERF_COUNT_HW_BRANCH_INSTRUCTIONS, PERF_COUNT_HW_BRANCH_MISSES and PERF_COUNT_HW_BUS_CYCLES.

BUT, I don't if I just create e.g. new PerfMeasurement(PerfMeasurement.BRANCH_MISSES | PerfMeasurement.BUS_CYCLES);

It looks like we can't put more than 4 hardware event counters in the same group.

Comment 3

[Mike Hommey [:glandium]]

Our code that gathers the data is correct. Unfortunately, it looks like the kernel only hands out 0 as value when we hit the hardware event counters number limit, and it does so for *all* hardware event counters, not only those that it failed to open :(

Comment 4

[Mike Hommey [:glandium]]

Turns out besides bug 642516, the perf measurement API works well on ARM (at least, on the Nexus S), because they happen the right number of PMU counters: they don't support 2 of the hardware counters, thus only requiring 5 PMU counters, which is exactly what I have available on the Nexus S.

On a core2duo, there are 4 counters, and one is taken by the NMI watchdog, so that leaves us with only 3 PMU counters.

On an i7, there are 7 counters, one is also taken by the NMI watchdog, so that leaves us with 6 PMU counters.

In both cases, we hit the unfortunate case where perf_event_open() returns ENOSPC for the counters that can't be opened due to the PMU counter shortage, and the unfortunate result that all hardware counters results are then 0.

The latter should eventually be fixed in the kernel, but that still leaves us with some unfortunate problems. We should probably check if we get ENOSPC from perf_event_open, and then test if that fucks up the results or not and do the most appropriate thing accordingly. Which could be either using more groups, or not caring about all hardware counters that don't fit in the PMU counters.

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

API was removed in Bug 1560425