From owner-freebsd-mips@FreeBSD.ORG Sun Mar 18 07:24:44 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5676106564A; Sun, 18 Mar 2012 07:24:44 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id A0EB28FC17; Sun, 18 Mar 2012 07:24:44 +0000 (UTC) Received: from [24.87.53.93] (helo=[192.168.1.132]) by hq.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1S9ATc-00038a-VX; Sun, 18 Mar 2012 00:24:29 -0700 From: Oleksandr Tymoshenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 18 Mar 2012 00:24:34 -0700 Message-Id: To: freebsd-mips@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1444\)) X-Mailer: Apple Mail (2.1444) Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: 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 [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: Subject: hwpmc(4) MIPS code refactoring / bugfixes X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 07:24:44 -0000 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.