Now
MAIN commitmail json YAML
src/sys/arch/i386/i386/pmc.c@1.25
/
diff
/
nxr@1.25
src/sys/arch/x86/include/sysarch.h@1.11 / diff / nxr@1.11
src/usr.bin/pmc/pmc.1@1.10 / diff / nxr@1.10
src/usr.bin/pmc/pmc.c@1.20 / diff / nxr@1.20
src/sys/arch/x86/include/sysarch.h@1.11 / diff / nxr@1.11
src/usr.bin/pmc/pmc.1@1.10 / diff / nxr@1.10
src/usr.bin/pmc/pmc.c@1.20 / diff / nxr@1.20
Switch to per-CPU PMC results, and completely rewrite the pmc(1) tool. Now
the PMCs are system-wide, fine-grained and more tunable by the user.
We don't do application tracking, since it would require to store the PMC
values in mdproc and starting/stopping the counters on each context switch.
While this doesn't seem to be particularly difficult to achieve, I don't
think it is really interesting; and if someone really wants to measure
the performance of an application, they can simply schedctl it to a cpu
and look at the PMC results for this cpu.
Note that several options are implemented but not yet used.
the PMCs are system-wide, fine-grained and more tunable by the user.
We don't do application tracking, since it would require to store the PMC
values in mdproc and starting/stopping the counters on each context switch.
While this doesn't seem to be particularly difficult to achieve, I don't
think it is really interesting; and if someone really wants to measure
the performance of an application, they can simply schedctl it to a cpu
and look at the PMC results for this cpu.
Note that several options are implemented but not yet used.