hwpmc(4) MIPS code refactoring / bugfixes
Oleksandr Tymoshenko
gonzo at bluezbox.com
Sun Mar 18 07:24:44 UTC 2012
Hello,
Proposed patch fixes some issues in hwpmc(4) and makes adding support
for more MIPS CPUs much easier. I'd appreciate reviews and any
feedback.
http://people.freebsd.org/~gonzo/mips/pmc-2.diff
Currently the only MIPS CPU type supported by hwpmc(4) is MIPS24K.
Performance Counter's design slightly varies between different
implementations but these differences could be abstracted to several
functions and structure that describes CPU:
- Structure contains CPU type, CPU class, CPU capabilities and counter
width
- Functions to access to counter (read and write)
- Function to generate Counter Control register value based on
requested PMC capabilities.
For platform I reviewed (Octeon and XLR/XLP) this set of
platform-specific code covers all the differences. Here is how support
for Octeon looks like with new code (libpmc part omitted):
http://people.freebsd.org/~gonzo/mips/hwpmc_octeon.c
hwpmc_mips.c contains generic code. All CPU-specific code like
hwpmc_mips24k.c or hwpmc_octeon.c should be added to builds on
per-platform basis.
Besides hwpmc/MIPS generalizations code, there are several other
fixes:
- PMC hook invocation moved from platform-specific code to cpu_intr.
It's the same approach as ast() invocation, although, there is no
reason to implement it in assembler.
- usr.sbin/pmcstat/pmcstat_log.c:
Properly detect base virtual address for ELF file. Some ELF files
might contain no PT_LOAD segment with zero offset. So we should
check if offset is less then segment's alignment.
- libexec/rtld-elf/mips/rtld_start.S
When jumping from rtld_start to program's entry point set RA to be
the same as PC in order to let backtrace routine know to go no
further.
- sys/sys/pmc.h
Fix PMC syscall on big-endian 64-bit platform.
- HWPMC_MIPS_BACKTRACE option
This option disables backtrace for obtaining call chain.
Statistics is still gathered but no caller information is
available. Implementing reliable backtrace on MIPS platform is
hard. It should combine knowledge about kernel symbols and some
heuristics. And even then some hand-crafted assembler code or
compiler optimization might lead to wandering into unchartered
memory area. For userland memory access it's not really important
but access to invalid region of kernel memory in critical section
(we do it in interrupt's filter context) will crash the system.
Current implementation *mostly* works OK but since with some
counters hitting invalid region is just a matter of time. So I
decided to switch backtracking by default. May be it's better
to just remove kernel part but some might be willing to risk
system stability for obtaining more detailed performance information.
I'm kind of on a fence with this one.
More information about the freebsd-mips
mailing list