I think there are two different use cases:
- measurement at thread level (top and the like) should report
instructions retired per unit of time, not %CPU.
We want to know how much work is being done.
The explanation on why so much/so little requires more information
(scheduler? cache misses? cpu throttling?)
- measurement at the CPU level (mpstat, etc) should report
both %CPU (as "time active" vs "wall clock time") and
active clock cycles per unit of time
(dividing by clock stretching factor if used, and
perhaps scaled to absolute max frequency and/or %CPU
if one wants a percentage).
%CPU tells us whether we are making full use of the available time,
and perhaps suggests to schedule threads differently if appropriate
Clock cycles tell us how much one CPU is affected by throttling
(manual, automatic, due to C-state exits, etc), and this is an orthogonal
indication on whether there is something at the system level that is
making the CPU underutilized
- measurement at thread level (top and the like) should report instructions retired per unit of time, not %CPU. We want to know how much work is being done. The explanation on why so much/so little requires more information (scheduler? cache misses? cpu throttling?)
- measurement at the CPU level (mpstat, etc) should report both %CPU (as "time active" vs "wall clock time") and active clock cycles per unit of time (dividing by clock stretching factor if used, and perhaps scaled to absolute max frequency and/or %CPU if one wants a percentage).
%CPU tells us whether we are making full use of the available time, and perhaps suggests to schedule threads differently if appropriate
Clock cycles tell us how much one CPU is affected by throttling (manual, automatic, due to C-state exits, etc), and this is an orthogonal indication on whether there is something at the system level that is making the CPU underutilized