http://blog.gmane.org/gmane.linux.oprofile hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.oprofile/10509 <pre>[PATCH] Fix up anonymous mapping support in operf to include vdso, stack, and heap Signed-off-by: Maynard Johnson &lt;maynardj&lt; at &gt;us.ibm.com&gt; This patch has been pushed to the perf-events branch, but review comments are welcome. --- libperf_events/operf_mangling.cpp | 2 +- libperf_events/operf_utils.cpp | 17 +++++++++++------ 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/libperf_events/operf_mangling.cpp b/libperf_events/operf_mangling.cpp index 5b31e29..5165807 100644 --- a/libperf_events/operf_mangling.cpp +++ b/libperf_events/operf_mangling.cpp &lt; at &gt;&lt; at &gt; -63,7 +63,7 &lt; at &gt;&lt; at &gt; mangle_filename(struct operf_sfile * last, struct operf_sfile const * sf, int co } else if (sf-&gt;is_anon) { values.flags |= MANGLE_ANON; values.image_name = mangle_anon(sf); -values.anon_name = "anon"; +values.anon_name = sf-&gt;image_name; } else { values.image_name = sf-&gt;image_name; } diff --git a/libperf_events/operf_utils.cpp b/libperf_events/operf_utils.cpp index 42eecce..9ee9b80 100644 --- a/libperf_</pre> Maynard Johnson 2012-05-25T14:00:32 http://comments.gmane.org/gmane.linux.oprofile/10507 <pre>Bugs item #3529111, was opened at 2012-05-23 08:05 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&amp;atid=116191&amp;aid=3529111&amp;group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: opjitconv failed to parse JIT dump header Initial Comment: The bug occurs on x86_64 Linux (Fedora 15) with oprofile installed from oprofile-0.9.6-21.fc15.x86_64.rpm while trying to profile JIT code produced by 32-bit application. The debug output of opjitconv shows: header: bfd-arch=9, bfd-mach=1, bfd_target_name=2-i386 Note that target name must be "elf32-i386" I assume that the "u64 timestamp" field of "jitheader" structure is 8-byte aligned</pre> SourceForge.net 2012-05-23T15:05:08 http://comments.gmane.org/gmane.linux.oprofile/10506 <pre>From: Andi Kleen &lt;ak&lt; at &gt;linux.intel.com&gt; Implement the ANY (any thread) extra bit for Intel CPUs. Needed for some of the new events. Signed-off-by: Andi Kleen &lt;ak&lt; at &gt;linux.intel.com&gt; --- libop/op_events.c | 3 +++ libop/op_events.h | 1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/libop/op_events.c b/libop/op_events.c index bbb0130..49b9563 100644 --- a/libop/op_events.c +++ b/libop/op_events.c &lt; at &gt;&lt; at &gt; -127,6 +127,9 &lt; at &gt;&lt; at &gt; unsigned parse_extra(const char *s) } else if (sscanf(s, "cmask=%x%n", &amp;w, &amp;o) &gt;= 1) { v |= (w &amp; EXTRA_CMASK_MASK) &lt;&lt; EXTRA_CMASK_SHIFT; s += o; +} else if (strisprefix(s, "any")) { +v |= EXTRA_ANY; +s += 3; } else { parse_error("Illegal extra field modifier"); } diff --git a/libop/op_events.h b/libop/op_events.h index 8cbb622..1a65a7a 100644 --- a/libop/op_events.h +++ b/libop/op_events.h &lt; at &gt;&lt; at &gt; -21,6 +21,7 &lt; at &gt;&lt; at &gt; extern "C" { #include "op_list.h" #define EXTRA_EDGE (1U &lt;&lt; 18) +#define EXTRA_ANY (1U &lt;&lt; 21) #define EXTRA_INV (1U &lt;&lt; 23) #define EXT</pre> Andi Kleen 2012-05-23T00:48:42 http://comments.gmane.org/gmane.linux.oprofile/10504 <pre>[PATCH] Change operf to create oprofile sample files during profiling instead of afterwards Previously, the 'operf-record' process read the perf_events sample data from the kernel and wrote it to a temporary output file (operf.data). Then, once the profiling session was completed, a conversion was performed on that data to put it into oprofile format, stored in the usual sample files in &lt;session-dir&gt;/samples/current. I noticed that when operf was run in system-wide mode, the temporary operf.data file was very large, and the conversion step was taking inordinately long (from several seconds on a laptop to over a minute on a large, busy server system. I've had a TODO comment in the operf.cpp code to investigate performing the conversion step in-flight (while profiling) versus waiting for the profiling to end. So I changed the operf-record process from writing the perf_events sample data to a file to writing to a pipe. Then I created a new operf-read process to read from the other end of that pipe and per</pre> Maynard Johnson 2012-05-22T22:05:40 http://comments.gmane.org/gmane.linux.oprofile/10503 <pre>[PATCH] Remove reset option from operf and replace with append option. By default, operf will now move old profile data from &lt;session_dir&gt;/samples/current to &lt;session_dir&gt;/samples/previous. If a 'previous' profile already existed, it will be replaced. If the --append option is passed, old profile data is left in place and new profile data will be added to it, and the 'previous' profile (if one existed) will remain untouched. operf man page updates: Aside from replacing the --reset option with the --append option, several unrelated fixes were made, including adding the missing --vmlinux option. This patch has been pushed up to the perf-events branch, but review comments are as always, welcome. Signed-off-by: Maynard Johnson &lt;maynardj&lt; at &gt;us.ibm.com&gt; --- doc/operf.1.in | 36 ++++++++++++---- pe_profiling/operf.cpp | 109 +++++++++++++++++++++++++++-------------------- 2 files changed, 90 insertions(+), 55 deletions(-) diff --git a/doc/operf.1.in b/doc/operf.1.in index 00b6b2c..00fb5f3 100644 ---</pre> Maynard Johnson 2012-05-22T14:15:32 http://comments.gmane.org/gmane.linux.oprofile/10498 <pre>Bugs item #3528383, was opened at 2012-05-20 04:43 Message generated for change (Comment added) made by maynardj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&amp;atid=116191&amp;aid=3528383&amp;group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Priority: 5 Private: No Submitted By: tombkeeper (tombkeeper) Assigned to: Nobody/Anonymous (nobody) Summary: oprofied failed to open device on mpc8572 linux version 2.6. Initial Comment: Linux version: 2.6.31 CPU: mpc8572, e500 core oprofile version: 0.9.7 1&gt;oprofile --init is ok 2&gt;oprofile --start failed, error output: Using 2.6+ OProfile kernel interface. Failed to open device. Possibly you have passed incorrect parameters. Check /var/log/messages.Couldn't start oprofiled. Check the log file "/var/lib/oprofile/samples/oprofiled.log" and kernel syslog 3&gt;check /var/log/message, nothing there.</pre> SourceForge.net 2012-05-21T12:00:35 http://comments.gmane.org/gmane.linux.oprofile/10496 <pre>What would be a good place to start to be able to get data from oprofile within JVM. i.e. i want to have JVM spawn a thread running the task of oprofiled. The data is then passed to and processed by the thread. Thanks Xin ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ oprofile-list mailing list oprofile-list&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oprofile-list </pre> Xin Tong 2012-05-21T04:16:15 http://comments.gmane.org/gmane.linux.oprofile/10495 <pre>I am using oprofile in a JVM environment. I have 2 questions 1. I am not very familiar with intel microarchitecrure, BR_INST_RETIRED means the branch decision is correct and the branch instruction is committed ? 2. Can one obtain the address branched to in the PMU registers ? Oprofile does not seem to provide it. Thanks Xin ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ oprofile-list mailing list oprofile-list&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oprofile-list </pre> Xin Tong 2012-05-20T17:28:28 http://comments.gmane.org/gmane.linux.oprofile/10494 <pre>Bugs item #3528383, was opened at 2012-05-20 04:43 Message generated for change (Tracker Item Submitted) made by tombkeeper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&amp;atid=116191&amp;aid=3528383&amp;group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: tombkeeper (tombkeeper) Assigned to: Nobody/Anonymous (nobody) Summary: oprofied failed to open device on mpc8572 linux version 2.6. Initial Comment: Linux version: 2.6.31 CPU: mpc8572, e500 core oprofile version: 0.9.7 1&gt;oprofile --init is ok 2&gt;oprofile --start failed, error output: Using 2.6+ OProfile kernel interface. Failed to open device. Possibly you have passed incorrect parameters. Check /var/log/messages.Couldn't start oprofiled. Check the log file "/var/lib/oprofile/samples/oprofiled.log" and kernel syslog </pre> SourceForge.net 2012-05-20T11:43:24 http://comments.gmane.org/gmane.linux.oprofile/10492 <pre>My OMAP randconfig build found this build error last night: arch/arm/oprofile/../../../drivers/oprofile/oprofile_perf.c:28: error: variably modified 'perf_events' at file scope This is caused because nr_cpumask_bits is a variable when we're building for a SMP system and CONFIG_CPUMASK_OFFSTACK is set. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Russell King - ARM Linux 2012-05-19T07:32:11 http://comments.gmane.org/gmane.linux.oprofile/10491 <pre>Hello everyone I need some help in cross compiling oprofile for ARM V7 architecture. Some hints would be really helpful. Regards Abdul ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Abdul Wahid Memon 2012-05-18T20:18:20 http://comments.gmane.org/gmane.linux.oprofile/10490 <pre>[PATCH] Make various minor cleanup fixes to operf - Remove or update stale comments - Add calls to cleanup() at error exit points - Add pre-check to verify user has access to sample data dir Signed-off-by: Maynard Johnson &lt;maynardj&lt; at &gt;us.ibm.com&gt; --- libperf_events/operf_utils.cpp | 6 +---- pe_profiling/operf.cpp | 41 ++++++++++++++++++++++++++++++++++----- 2 files changed, 36 insertions(+), 11 deletions(-) diff --git a/libperf_events/operf_utils.cpp b/libperf_events/operf_utils.cpp index 1d18f32..4ff99c0 100644 --- a/libperf_events/operf_utils.cpp +++ b/libperf_events/operf_utils.cpp &lt; at &gt;&lt; at &gt; -280,7 +280,6 &lt; at &gt;&lt; at &gt; static struct operf_transient * __get_operf_trans(struct sample_data * data) proc = it-&gt;second; trans.cur_procinfo = proc; } else { -// TODO /* This can happen for the following reasons: * - We get a sample before getting a COMM or MMAP * event for the process being profiled &lt; at &gt;&lt; at &gt; -291,10 +290,7 &lt; at &gt;&lt; at &gt; static struct operf_transient * __get_operf_trans(struct samp</pre> Maynard Johnson 2012-05-17T14:12:08 http://comments.gmane.org/gmane.linux.oprofile/10487 <pre>The new perf_events-based 'operf' tool (in the perf-events branch) currently has a "--reset" option which will clear out old profile data. If the user does not pass the "--reset" option, then new profile data that operf collects will be appended to existing profile data. I designed the interface this way to mimic the way that opcontrol-based profiling works -- i.e., the user needs to do 'opcontrol --reset' prior to profiling unless they want to append new data to old. My guess is that oprofile users very infrequently want or need to append profile data, so I am proposing that operf's interface be changed as follows: Remove the "--reset" option and add an "--append" option. The resulting behavior would clear out old profile data by default unless the "--append" option is passed. Does anyone have an opinion, yea or nay, on this? Thanks. -Maynard ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the way</pre> Maynard Johnson 2012-05-16T18:32:37 http://comments.gmane.org/gmane.linux.oprofile/10484 <pre>[PATCH] Flesh out operf JIT support so old jitdump files are removed This patch makes opjitconv delete old jitdump files when invoked by operf. Only jitdump files owned by the user who is running operf will be deleted. This patch is necessary because the only other way that old jitdump files are deleted is by way of opcontrol, and operf users should not have to use opcontrol at all. This patch has been committed to the perf-events branch, but review comments are welcome. Signed-off-by: Maynard Johnson &lt;maynardj&lt; at &gt;us.ibm.com&gt; --- opjitconv/opjitconv.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++- opjitconv/opjitconv.h | 6 ++ pe_profiling/operf.cpp | 4 +- 3 files changed, 148 insertions(+), 3 deletions(-) diff --git a/opjitconv/opjitconv.c b/opjitconv/opjitconv.c index 9da0c82..3583f17 100644 --- a/opjitconv/opjitconv.c +++ b/opjitconv/opjitconv.c &lt; at &gt;&lt; at &gt; -72,6 +72,9 &lt; at &gt;&lt; at &gt; struct jitentry ** entries_address_ascending; int debug; /* indicates opjitconv invoked by non-root user via operf */ </pre> Maynard Johnson 2012-05-16T17:39:25 http://comments.gmane.org/gmane.linux.oprofile/10483 <pre>Hello everyone I need some hints on how to proceed further. I am sorry if this is not the right place to ask this type of question. I need to collect some performance counters using perf tool. But I am always getting the following output. Kernel: 2.6.35-7 Performance counter stats for 'ls': 2.624511 task-clock-msecs # 0.677 CPUs 0 context-switches # 0.000 M/sec 0 CPU-migrations # 0.000 M/sec 62 page-faults # 0.024 M/sec &lt;not counted&gt; cycles &lt;not counted&gt; instructions &lt;not counted&gt; branches &lt;not counted&gt; branch-misses &lt;not counted&gt; cache-references &lt;not counted&gt; cache-misses 0.003875716 seconds time elapsed I have recompiled the kernel to enable the support for events and counters but to no avail. Any help or tips would be beneficial. Regards Abdul -----------------------------------------------------------------------------</pre> Abdul Wahid Memon 2012-05-16T17:33:17 http://comments.gmane.org/gmane.linux.oprofile/10482 <pre>Hi all, We've encountered an issue with sampling spin locks using oprofile in 64 bit environments running linux 2.6.18. Under 32 bit where we have proper results, assembly code for _spin_lock_irqsave is significantly longer than the code under 64 bit. The latter includes a jump into .text.lock.spinlock which does all the hard work. Could it be that oprofile fails to account time spent in a text section to the correct function? It doesn't appear to be falsely accounted elsewhere. Any insights will be appreciated. Thanks, Jonathan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ oprofile-list mailing list oprofile-list&lt; at &gt;</pre> Jonathan Kukin 2012-05-15T17:03:07 http://comments.gmane.org/gmane.linux.oprofile/10479 <pre>[PATCH] Fix patch committed on Feb 29, 2012 so that samples from PID 0 are not discarded. Without this patch, we were not recording samples from process 0. Additionally, we were incorrectly incrementing the new OPD_NO_APP_KERNEL_SAMPLE stat for such discarded samples. It's a straightforward, obvious fix, so I committed it already. But review comments are still welcome. Signed-off-by: Maynard Johnson &lt;maynardj&lt; at &gt;us.ibm.com&gt; --- daemon/opd_sfile.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/daemon/opd_sfile.c b/daemon/opd_sfile.c index 170abbf..7f4a01c 100644 --- a/daemon/opd_sfile.c +++ b/daemon/opd_sfile.c &lt; at &gt;&lt; at &gt; -294,9 +294,9 &lt; at &gt;&lt; at &gt; struct sfile * sfile_find(struct transient const * trans) opd_stats[OPD_LOST_KERNEL]++; return NULL; } -// We *know* that PID 1 and 2 are pure kernel context tasks, so +// We *know* that PID 0, 1, and 2 are pure kernel context tasks, so // we always want to keep these samples. -if ((trans-&gt;tgid == 1) || (trans-&gt;tgid == 2))</pre> Maynard Johnson 2012-05-14T16:40:09 http://comments.gmane.org/gmane.linux.oprofile/10465 <pre>Hi guys, When I tried to start Oprofile on Xen virtual machines, I encountered some problem. Physical CPU: Intel E5620. Xen : version 4.1.1 XenOprofile : version 0.9.5 Oprofile installed on VM: version 0.9.7 Problem: The opcontrol cannot start on VM (dom1), while it works well on dom0 . Scene: Run cmd on dom0: #opcontrol --start-daemon --active-domains=0,1 --event=LLC_MISSES:100000:0:1:1 --xen=/boot/xen-syms-4.1.1 --vmlinux=/usr/src/kernels/vmlinux It's OK. Output: Using 2.6+ OProfile kernel interface. Reading module info. Using log file /var/lib/oprofile/samples/oprofiled.log Daemon started But When I run cmd on dom1: #opcontrol --reset #opcontrol --start --vmlinux=/usr/src/linux-source-2.6.32/vmlinux --xen=/boot/xen-syms-4.1.1 Error. Output: Not enough hardware counters. Need 1 counters but only has 0. and, when i run: #ls /dev/opr</pre> Tao Sun 2012-05-11T00:39:21 http://comments.gmane.org/gmane.linux.oprofile/10441 <pre>Dear There, I am trying to install oprofile on LINUX Octeon 2.6.32.27-cavium-octeon but when I run the Command ./configure --with-linux, i get two problems 1. no kernel support for oprofile 2. no suitably configured kernel include tree found need help to solve this problem </pre> Farrukh Mahmood 2012-05-08T13:10:22 http://comments.gmane.org/gmane.linux.oprofile/10435 <pre>[PATCH] Fix regression to operf system-wide profiling caused by previous patch Signed-off-by: Maynard Johnson &lt;maynardj&lt; at &gt;us.ibm.com&gt; --- libperf_events/operf_process_info.h | 39 ++++++++++++++++++----------------- libperf_events/operf_utils.cpp | 2 +- 2 files changed, 21 insertions(+), 20 deletions(-) diff --git a/libperf_events/operf_process_info.h b/libperf_events/operf_process_info.h index 1d9a791..ab4ff94 100644 --- a/libperf_events/operf_process_info.h +++ b/libperf_events/operf_process_info.h &lt; at &gt;&lt; at &gt; -51,21 +51,13 &lt; at &gt;&lt; at &gt; struct operf_mmap { class operf_process_info { public: operf_process_info(pid_t tgid, const char * appname, bool app_arg_is_fullname, bool is_valid); -bool is_valid(void) { return (valid &amp;&amp; appname_valid()); } +bool is_valid(void) { return (valid); } void process_new_mapping(struct operf_mmap * mapping); void process_deferred_mappings(std::string app_shortname); std::string get_app_name(void) { return _appname; } void add_deferred_mapping(struct operf_mmap * mapping)</pre> Maynard Johnson 2012-05-03T19:14:48 http://comments.gmane.org/gmane.linux.oprofile/10434 <pre>[PATCH] Make new --separate-thread option for operf This patch reverses the earlier decision to do "separate=thread" type of functionality by default. So now there is a command line option to operf called "--separate-thread". I decided to make this an option for two reasons: 1) operf run in system-wide mode required the user to either pass a tgid spec or to use "--merge=tgid" or the resulting report was unreadable; 2) typically, the Java JIT compiler will spawn threads to execute JITed code; so when using operf to profile a single Java app, the resulting report is usually unreadable without using a tid spec or "--merge=tid". Signed-off-by: Maynard Johnson &lt;maynardj&lt; at &gt;us.ibm.com&gt; --- doc/operf.1.in | 32 ++++++++++++++++++++++---------- libperf_events/operf_mangling.cpp | 8 +++++--- libperf_events/operf_utils.h | 1 + pe_profiling/operf.cpp | 10 +++------- 4 files changed, 31 insertions(+), 20 deletions(-) diff --git a/doc/operf.1.in b/doc/operf.1.in index c</pre> Maynard Johnson 2012-05-03T19:52:56 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.oprofile