Re: Regarding vmlinux file for opcontrol --init

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