From: Breno L. <br...@br...> - 2012-03-05 13:51:43
|
Hi, I just tested operf on a Power7 machine and it seems to be working fine. Although when running: operf sleep 1, it sleeps forever, and even ^C doesn't work. (^Z works and then I can kill the process). Doing a strace, I found that operf is in a loop as shown above: mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 munmap(0xfffad340000, 1072) = 0 mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 munmap(0xfffad340000, 1072) = 0 mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 munmap(0xfffad340000, 1072) = 0 mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 munmap(0xfffad340000, 1072) = 0 mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 munmap(0xfffad340000, 1072) = 0 mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 munmap(0xfffad340000, 1072) = 0 I am running perf-events branch, and my last commit is 35b8a590617dffb56b5da95c826499c59bde4062. Thanks Breno -- Breno Leitão Linux Technology Center Phone: +55 16 8115-3915 E-Mail: br...@br... |
From: Maynard J. <may...@us...> - 2012-03-06 17:57:44
|
On 03/05/2012 7:51 AM, Breno Leitao wrote: > Hi, > > I just tested operf on a Power7 machine and it seems to be working fine. > Although when running: operf sleep 1, it sleeps forever, and even ^C > doesn't work. (^Z works and then I can kill the process). Hi, Breno, Thanks for testing operf. I fixed the problem you reported, and it's available in the perf-events branch in the shared git repo. Be aware, though, that using the default event and count (CYCLES:100000) for "sleep 1" will result in very few samples, most of which will be in the kernel -- and kernel profiling is not yet implemented in operf. So running opreport on the resulting profile may give you the "No sample file found" message. A higher sampling frequency should give you some valid sample files (e.g., 'operf -e CYCLES:20000 sleep 1'). -Maynard > > Doing a strace, I found that operf is in a loop as shown above: > > mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 > munmap(0xfffad340000, 1072) = 0 > mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 > munmap(0xfffad340000, 1072) = 0 > mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 > munmap(0xfffad340000, 1072) = 0 > mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 > munmap(0xfffad340000, 1072) = 0 > mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 > munmap(0xfffad340000, 1072) = 0 > mmap(NULL, 1072, PROT_READ, MAP_SHARED, 14, 0) = 0xfffad340000 > munmap(0xfffad340000, 1072) = 0 > > > I am running perf-events branch, and my last commit is > 35b8a590617dffb56b5da95c826499c59bde4062. > > Thanks > Breno |
From: Breno L. <br...@br...> - 2012-03-12 18:39:52
|
Hi Maynard, On 03/06/2012 02:57 PM, Maynard Johnson wrote: > On 03/05/2012 7:51 AM, Breno Leitao wrote: >> Hi, >> >> I just tested operf on a Power7 machine and it seems to be working fine. >> Although when running: operf sleep 1, it sleeps forever, and even ^C >> doesn't work. (^Z works and then I can kill the process). > Hi, Breno, > Thanks for testing operf. I fixed the problem you reported, and it's available > in the perf-events branch in the shared git repo. Thanks, it's now working properly. :-) But, at the same time, I got a bad state on the same power, i.e. unable to continue using operf after the following commands: [root@perfjuno4 oprofile]# operf ping 192.168.100.1 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. <snip> 64 bytes from 192.168.100.1: icmp_seq=38 ttl=64 time=0.041 ms ^CTotal bytes recorded from perf events: 49088 Use '--session-dir=/root/breno/oprofile/oprofile_data' with opreport and other post processing tools to view your profile data. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [root@perfjuno4 oprofile]# opreport --session-dir=/root/breno/oprofile/oprofile_data -l warning: /[vdso] could not be found. CPU: ppc64 POWER7, speed 3550 MHz (estimated) Counted CYCLES events (Processor Cycles) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name symbol name 36 30.2521 ping /bin/ping 25 21.0084 libc-2.12.so .__libc_recvmsg 23 19.3277 libc-2.12.so .__sched_yield 17 14.2857 [vdso] /[vdso] 7 5.8824 libc-2.12.so .__gettimeofday 5 4.2017 libc-2.12.so .__syscall_error 2 1.6807 libc-2.12.so ._IO_vfprintf@@GLIBC_2.4 2 1.6807 libc-2.12.so .__errno_location 1 0.8403 libc-2.12.so ._IO_file_write@@GLIBC_2.3 1 0.8403 libc-2.12.so ._IO_file_xsputn@@GLIBC_2.3 [root@perfjuno4 oprofile]# opreport slep 10 error: no sample files found: profile specification too strict ? [root@perfjuno4 oprofile]# operf sleep 10 Unexpected error running operf: Device or resource busy Please use the opcontrol command instead of operf. After that, operf doesn't work anymore, Even after a opcontrol --stop/--start. More than that, oprofile module can not be unloaded, since it is busy, even when opcontrol is stopped. Looking into dmesg, I see: reserve_pmc_hardware: PMC hardware busy (reserved by caller d000000018a43638) reserve_pmc_hardware: PMC hardware busy (reserved by caller d000000018a43638) Not sure if this is a oprofile or a perf issue. I remember seeing this in the past. Thanks Breno |
From: Maynard J. <may...@us...> - 2012-03-13 13:26:17
|
On 03/12/2012 01:39 PM, Breno Leitao wrote: > Hi Maynard, > > On 03/06/2012 02:57 PM, Maynard Johnson wrote: >> On 03/05/2012 7:51 AM, Breno Leitao wrote: >>> Hi, >>> >>> I just tested operf on a Power7 machine and it seems to be working fine. >>> Although when running: operf sleep 1, it sleeps forever, and even ^C >>> doesn't work. (^Z works and then I can kill the process). >> Hi, Breno, >> Thanks for testing operf. I fixed the problem you reported, and it's available >> in the perf-events branch in the shared git repo. > Thanks, it's now working properly. :-) > > But, at the same time, I got a bad state on the same power, i.e. unable > to continue using operf after the following commands: > > > [root@perfjuno4 oprofile]# operf ping 192.168.100.1 > PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. > <snip> > 64 bytes from 192.168.100.1: icmp_seq=38 ttl=64 time=0.041 ms > ^CTotal bytes recorded from perf events: 49088 > > Use '--session-dir=/root/breno/oprofile/oprofile_data' > with opreport and other post processing tools to view your profile data. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [root@perfjuno4 oprofile]# opreport > --session-dir=/root/breno/oprofile/oprofile_data -l > warning: /[vdso] could not be found. > CPU: ppc64 POWER7, speed 3550 MHz (estimated) > Counted CYCLES events (Processor Cycles) with a unit mask of 0x00 (No > unit mask) count 100000 > samples % image name symbol name > 36 30.2521 ping /bin/ping > 25 21.0084 libc-2.12.so .__libc_recvmsg > 23 19.3277 libc-2.12.so .__sched_yield > 17 14.2857 [vdso] /[vdso] > 7 5.8824 libc-2.12.so .__gettimeofday > 5 4.2017 libc-2.12.so .__syscall_error > 2 1.6807 libc-2.12.so ._IO_vfprintf@@GLIBC_2.4 > 2 1.6807 libc-2.12.so .__errno_location > 1 0.8403 libc-2.12.so ._IO_file_write@@GLIBC_2.3 > 1 0.8403 libc-2.12.so ._IO_file_xsputn@@GLIBC_2.3 > [root@perfjuno4 oprofile]# opreport slep 10 > error: no sample files found: profile specification too strict ? > [root@perfjuno4 oprofile]# operf sleep 10 > Unexpected error running operf: Device or resource busy > Please use the opcontrol command instead of operf. > > After that, operf doesn't work anymore, Even after a opcontrol > --stop/--start. > More than that, oprofile module can not be unloaded, since it is busy, > even when opcontrol is stopped. > > Looking into dmesg, I see: > reserve_pmc_hardware: PMC hardware busy (reserved by caller > d000000018a43638) > reserve_pmc_hardware: PMC hardware busy (reserved by caller > d000000018a43638) ^^^^^--- This is almost certainly the oprofile kernel driver reserving the PMC hardware. Both oprofile and perf will call this function on ppc64 systems to avoid colliding with one another. This is because oprofile hogs the whole PMU and can't share it. There are no other clients of this function, and since the caller address above is a module (and oprofile kernel driver is usually built as a module), I surmise that someone else on your system started up oprofile unbeknownst to you. -Maynard > > > Not sure if this is a oprofile or a perf issue. I remember seeing this > in the past. > > Thanks > Breno > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |