Re: Regarding vmlinux file for opcontrol --init
Michael Petlan <[email protected]>
| Newsgroups | gmane.linux.oprofile |
|---|---|
| Message-ID | <alpine.LRH.2.20.1703021724320.19588@Diego> |
Hi, Broadwell PMU support was added to linux kernel by commit 91f1b70582c62576f429cf78d53751c66677553d [1] --> you might want to check whether your kernel has this patch: commit 91f1b70582c62576f429cf78d53751c66677553d Author: Andi Kleen <[email protected]> Date: Tue Feb 17 18:18:05 2015 -0800 perf/x86/intel: Add Broadwell core support That patch came into linux v4.1, so your Ubuntu 15.10 should contain it (there should be 4.2 or higher). You're right, PMU seems not to be initialized correctly. Kernel needs to be built with CONFIG_PERF_EVENTS=y, however, I expect that your one is, otherwise it would not attempt to init the PMU. The log really looks that your kernel does not know what to do with '61' (Broadwell). So in case the kernel is new enough to support it, then something is probably broken. You might try to update to some newer kernel to solve it. It is also possible (but does not look very probable), that the message in log is caused by Xen, but I think it would look different in such case (unsuccessful init instead of "no PMU driver")... But this is what I think, I am not sure. Michael [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f1b70582c62576f429cf78d53751c66677553d On Thu, 2 Mar 2017, dhara buch wrote: > Hi, > > I checked the status of PMU. Referring to log, I found a note as : > > Performance Events: unsupported p6 CPU model he 61 no PMU driver, software events only. > > 61 is my CPU model No. > > As per my study, if I am not wrong this is given by linux, not Xen . Due to this probably PMU is not getting enabled. > > Can you help me out in solving this? > > Thanks > > > On Tue, Feb 28, 2017 at 6:20 PM, Michael Petlan <[email protected]> wrote: > On Tue, 28 Feb 2017, dhara buch wrote: > I installed oprofile-1.1.0. When I executed ophelp -r command, it gave me output as 'Intel Broadwell Microarchitecture as output'. > > > This is correct. The CPU has been detected correctly. > > > Then I executed operf command without any option, but it gave me an error as follows: > ou > Your kernel's performance event subsystem does not support your processor type. > > > It looks like the VM guest has no access to the HW counters. > Xen should be able to support it, however, I don't have any > experience with Xen, thus nor with running OProfile there. > > Google says that you need to boot with 'vpmu=1'. Or try to > search for "enable PMU in Xen guests" or similar. > > You can verify that PMU is working by: > > $ ocount ls > Events were actively counted for 2669610 nanoseconds. > Event counts (actual) for /usr/bin/ls: > Event Count % time counted > cpu_clk_unhalted 3,982,864 100.00 > > or using perf (linux-tools package), by > > $ perf stat -e cycles ls > Performance counter stats for 'ls': > 3,737,940 cycles > 0.013856521 seconds time elapsed > > I think this should work without any necessary patches if > you enable PMU for the guest. > > Cheers, > Michael > > > What is the solution? > > Thank y > > On Tue, Feb 28, 2017 at 12:40 PM, dhara buch <[email protected]> wrote: > > ---------- Forwarded message ---------- > From: Michael Petlan <[email protected]> > Date: Tue, Feb 28, 2017 at 12:00 AM > Subject: Re: Regarding vmlinux file for opcontrol --init > To: dhara buch <[email protected]> > Cc: [email protected] > > > On Mon, 27 Feb 2017, dhara buch wrote: > Hello, > > Thanks a lot for the prompt reply. > > > Hi, you're welcome. Please do Reply-To-All to make sure it all > goes also to [email protected] --> others > might appreciate the list history for solving similar problems > in future. > > > I am using i7 core processor. When I executed ophelp -r, the displayed CPU type was 'Intel Architectural Perfmon'. > > > The "Core i7" is too generic nomenclature. Could you please send > the output of `lscpu` or attach /proc/cpuinfo (one core is enough)? > The important fields are cpu model and cpu family: > > Vendor ID: GenuineIntel > CPU family: 6 > Model: 78 > > Afterwards, when I execute opcontrol --vmlinux=(uncompressed form of vmlinuz) command, the CPU type gets changed to 'CPU with timer Interrupt'. > > The problem would be in uncompressed file? I am also not much clear about the proper way to get vmlinux from vmlinuz file. > > > I think you decompressed the file correctly. However, this does > not affect the CPU identification/understanding. > > Regarding to vmlinux: > > You can even skip vmlinux by using "--no-vmlinux" switch with > opcontrol. That will mark all the samples captured in kernel as > "no-vmlinux" and no vmlinux file is needed. However, this is no > good if you want to profile kernelspace. > > Your problem is that your CPU is not identified by OProfile. > If you send me the `lscpu` output or the /proc/cpuinfo file > contents, I might figure out why. > > However, it is very probable, that your CPU is supported by the > latest OProfile 1.1 and I encourage you to try that one instead. > > ------------ > > Some deeper explanation: > > There are two modes oprofile knows, let's call them "opcontrol-mode" > and "operf-mode". > > -- > > 1) "opcontrol-mode" is obsolete and consists of a kernel module, > a profiling daemon and a controller (opcontrol). By this controller, > you signal the profiling daemon to start/stop/reset profiling, etc. > > The event sources can be either HW events or TIMER interrupt. The > TIMER interrupt is a fallback used by the daemon when HW events are > not detected. They are not detected when the CPU is unknown or not > supported. It might be also totally different architecture which > does not support any HW events, or, the HW events might be disabled > (e.g. you are running a virtual machine and the hypervisor does not > support/enable that for its guests). > > The "TIMER interrupts" is a software-emulated event that is used > when the HW events are simply not available. > > Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf- > mode". So using "TIMER interrupts" might be a reason why a user might > want to stick with this legacy "opcontrol-mode". > > The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is > the latest OProfile that supports it. > > -- > > 2) "operf-mode" is far better replacement for the previous mode. It > does not need any daemon and kernel module, the usage is much more > simple and it has lots of other advantages. > > Basically, the only disadvantage is that it does NOT support the > TIMER interrupts fallback. Thus, when the HW events are not enabled/ > detected/usable/supported/etc, you cannot fallback to the TIMER mode. > > If you do not want to use the TIMER mode, there is basically no > reason for not using "operf-mode" instead, thus there is nothing to > be lost by updating to oprofile-1.1. > > -------------------- > > So, I recommend to update to the latest OProfile and try out the > operf mode: > > 1) `ophelp -r` should still test the CPU identification > > I believe, your CPU will be supported after updating, but I cannot > be sure without knowing the model/family numbers. > > 2) `ocount ls` should report some numbers (this tests whether the > HW events can be used). > > 3) `ophelp | less` will print all the HW events available to you > > 4) Basic profiling: > > operf ls > opreport > > 5) or let's profile systemwide and with kernel: > > operf -s --vmlinux /your/path/to/vmlinux > # wait here for a while > ^C > opreport > > ------------------------ > > Hope it helps. > Michael > > > Dhara Buch > > On Mon, Feb 27, 2017 at 10:24 PM, Michael Petlan <[email protected]> wrote: > On Mon, 27 Feb 2017, dhara buch wrote: > Hello, > > > Hi Dhara, > > > I have installed Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile with' > opcontrol --init command, which requires uncompressed vmlinux file with --vmlinux option. > > I have tried to uncompress the present vmlinuz with extract-vmlinux script. The file gts uncompressed,but when I init opcontrol with this > uncompressed > file, my CPU > type gets wrongly > identified. Hence, although the hardware events are supported by the processor, 'timer' mode gets set and event monitoring doesn't become > possible. > > > You can test the CPU identification by running `ophelp -r` which should > print what OProfile thinks your CPU is, such as: > > $ ophelp -r > Intel Skylake microarchitecture > > What is your CPU type? OProfile 0.9.9 is pretty old, it might not support > the newer processors. Consider using the latest OProfile 1.1. It might not > fit you if you need the legacy opcontrol-based profiling mode (which was > removed from 1.0 and above), but since you probably want to use the CPU > hardware events, I guess, operf-mode (and oprofile-1.1) should serve you > well. > > Regards, > Michael > > > I would be thankful if anybody can guide me to solve this problem. > > Dhara Buch > > > > > > > > > > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ oprofile-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oprofile-list