From: Maynard J. <may...@us...> - 2014-06-12 17:59:11
|
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "oprofile". The branch, master has been updated via d3e89565c34016cbdbd9e2df518f90111ab83182 (commit) from 98f57a6c0e32bc6080a50e1cdd769b9ff78108bc (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit d3e89565c34016cbdbd9e2df518f90111ab83182 Author: Maynard Johnson <may...@us...> Date: Thu Jun 12 12:38:48 2014 -0500 Fix vsyscall sample collection on x86 architectures On certain architectures running older kernels (x86* on kernel 3.0 and older, I think), a static mapping is placed into every process's memory map to provide vsyscall functionality. This mapping is labeled '[vsyscall]'. This mapping is a mechanism for reducing latency of a handful of calls (e.g., gettimeofday) that would otherwise require a more expensive system call. When operf is used to collect a profile on an application that uses vsyscall functions, the samples taken within the vsyscall mapping are lost. For example, profiling the program below [1] would result in a "Lost samples detected" message from operf, and the operf.log would show something like the following: -- OProfile/operf Statistics -- Nr. non-backtrace samples: 71964 Nr. kernel samples: 203 Nr. user space samples: 71761 Nr. samples lost due to sample address not in expected range for domain: 0 Nr. lost kernel samples: 0 Nr. samples lost due to sample file open failure: 0 Nr. samples lost due to no permanent mapping: 63590 ^-- BAD!! For some reason (which I don't care to investigate since vsyscall is now replaced by vDSO), the kernel's perf_events subsystem does not send a PERF_RECORD_MMAP message for this mapping. This patch adds a function to synthesize such a message so that samples taken in the vsyscall memory range can be correctly attributed. Note that when using operf with "--pid" or "--system-wide", this new function need not be called since when either of those two options are used, operf already manually generates PERF_RECORD_MMAP messages for all memory mappings for the process(es) being profiled. However, a fix was needed in that area of operf to recognize the '[vsyscall]' label and to create the corresponding PERF_RECORD_MMAP for it. [1] ------------------ int main(void) { struct timeval time; int rc; while (1) rc = gettimeofday(&time, NULL); return rc; } ------------------- Signed-off-by: Maynard Johnson <may...@us...> ----------------------------------------------------------------------- Summary of changes: libperf_events/operf_counter.cpp | 2 + libperf_events/operf_utils.cpp | 69 ++++++++++++++++++++++++++++++++++++++ libperf_events/operf_utils.h | 1 + 3 files changed, 72 insertions(+), 0 deletions(-) hooks/post-receive -- oprofile |