Date: Sun, 18 Mar 2012 00:24:34 -0700 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: freebsd-mips@freebsd.org Subject: hwpmc(4) MIPS code refactoring / bugfixes Message-ID: <A9B53A21-71EF-43A1-9354-A1F17013C496@bluezbox.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A9B53A21-71EF-43A1-9354-A1F17013C496>