Discussion:
Regarding vmlinux file for opcontrol --init
(too old to reply)
dhara buch
2017-02-27 16:33:37 UTC
Permalink
Raw Message
Hello,

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.

I would be thankful if anybody can guide me to solve this problem.

Dhara Buch
Michael Petlan
2017-02-27 16:54:28 UTC
Permalink
Raw Message
Post by dhara buch
Hello,
Hi Dhara,
Post by dhara buch
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
Post by dhara buch
I would be thankful if anybody can guide me to solve this problem.
Dhara Buch
Michael Petlan
2017-02-27 18:30:15 UTC
Permalink
Raw Message
Post by dhara buch
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 oprofile-***@lists.sourceforge.net --> others
might appreciate the list history for solving similar problems
in future.
Post by dhara buch
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
Post by dhara buch
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
Post by dhara buch
Dhara Buch
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
$ 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
dhara buch
2017-02-28 07:10:34 UTC
Permalink
Raw Message
---------- Forwarded message ----------
From: Michael Petlan <***@redhat.com>
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Post by dhara buch
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 oprofile-***@lists.sourceforge.net --> others
might appreciate the list history for solving similar problems
in future.
Post by dhara buch
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
Post by dhara buch
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
Post by dhara buch
Dhara Buch
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
$ 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
dhara buch
2017-02-28 07:33:34 UTC
Permalink
Raw Message
I installed oprofile-1.1.0. When I executed ophelp -r command, it gave me
output as 'Intel Broadwell Microarchitecture as output'.

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.

What is the solution?

Thank y
Post by dhara buch
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Post by dhara buch
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
might appreciate the list history for solving similar problems
in future.
Post by dhara buch
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)?
Vendor ID: GenuineIntel
CPU family: 6
Model: 78
Afterwards, when I execute opcontrol --vmlinux=(uncompressed form of
Post by dhara buch
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.
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.
------------
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
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
operf ls
opreport
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport
------------------------
Hope it helps.
Michael
Post by dhara buch
Dhara Buch
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
$ 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
Michael Petlan
2017-02-28 12:50:57 UTC
Permalink
Raw Message
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.
 
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
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
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)?
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.
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.
------------
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
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
operf ls
opreport
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport
------------------------
Hope it helps.
Michael
Dhara Buch
            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
      $ 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
dhara buch
2017-03-02 14:43:28 UTC
Permalink
Raw Message
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
Post by Michael Petlan
Post by dhara buch
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.
Post by dhara buch
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.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
Event Count % time counted
cpu_clk_unhalted 3,982,864 100.00
or using perf (linux-tools package), by
$ perf stat -e cycles 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
Post by dhara buch
What is the solution?
Thank y
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
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)?
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.
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.
------------
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
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
operf ls
opreport
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 <
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
$ 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
Michael Petlan
2017-03-02 16:49:38 UTC
Permalink
Raw Message
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 <***@linux.intel.com>
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
Hi,
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
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.
 
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.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
        Event                   Count                    % time counted
        cpu_clk_unhalted        3,982,864                100.00
or using perf (linux-tools package), by
$ perf stat -e cycles 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
      ---------- Forwarded message ----------
      Date: Tue, Feb 28, 2017 at 12:00 AM
      Subject: Re: Regarding vmlinux file for opcontrol --init
            Hello,
            Thanks a lot for the prompt reply.
      Hi, you're welcome. Please do Reply-To-All to make sure it all
      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)?
      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.
      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.
      ------------
      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
      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
      operf ls
      opreport
      operf -s --vmlinux /your/path/to/vmlinux
      # wait here for a while
      ^C
      opreport
      ------------------------
      Hope it helps.
      Michael
            Dhara Buch
                        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
                  $ 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
dhara buch
2017-03-03 12:31:49 UTC
Permalink
Raw Message
Hello,

I downloaded the patch suggested by you, which was for perf_event_intel.c
file.

Although I did not build kernel by source, but I downloaded the source by
the following command:

*git clone git://kernel.ubuntu.com/ubuntu/ubuntu-wily.git
<http://kernel.ubuntu.com/ubuntu/ubuntu-wily.git>* (as the release name
ius wily)

In ubuntu-wily, I studied the source code of
/arch/x86/kernel/cpu/perf_event_intel.c
file where I found the following code in intel_pmu_init function:






































* case 61: /* 14nm Broadwell Core-M */ case 86: /* 14nm Broadwell Xeon
D */ case 71: /* 14nm Broadwell + GT3e (Intel Iris Pro graphics) */
case 79: /* 14nm Broadwell Server */ x86_pmu.late_ack = true;
memcpy(hw_cache_event_ids, hsw_hw_cache_event_ids,
sizeof(hw_cache_event_ids)); memcpy(hw_cache_extra_regs,
hsw_hw_cache_extra_regs, sizeof(hw_cache_extra_regs)); /*
L3_MISS_LOCAL_DRAM is BIT(26) in Broadwell */
hw_cache_extra_regs[C(LL)][C(OP_READ)][C(RESULT_MISS)] = HSW_DEMAND_READ
| BDW_L3_MISS|HSW_SNOOP_DRAM;
hw_cache_extra_regs[C(LL)][C(OP_WRITE)][C(RESULT_MISS)] =
HSW_DEMAND_WRITE|BDW_L3_MISS|
HSW_SNOOP_DRAM;
hw_cache_extra_regs[C(NODE)][C(OP_READ)][C(RESULT_ACCESS)] =
HSW_DEMAND_READ|
BDW_L3_MISS_LOCAL|HSW_SNOOP_DRAM;
hw_cache_extra_regs[C(NODE)][C(OP_WRITE)][C(RESULT_ACCESS)] =
HSW_DEMAND_WRITE|
BDW_L3_MISS_LOCAL|HSW_SNOOP_DRAM; intel_pmu_lbr_init_hsw();
x86_pmu.event_constraints = intel_bdw_event_constraints;
x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
x86_pmu.extra_regs = intel_snbep_extra_regs; x86_pmu.pebs_aliases =
intel_pebs_aliases_snb; /* all extra regs are per-cpu when HT is on
*/ x86_pmu.flags |= PMU_FL_HAS_RSP_1; x86_pmu.flags |=
PMU_FL_NO_HT_SHARING; x86_pmu.hw_config = hsw_hw_config;
x86_pmu.get_event_constraints = hsw_get_event_constraints;
x86_pmu.cpu_events = hsw_events_attrs; x86_pmu.limit_period =
bdw_limit_period; pr_cont("Broadwell events, "); break;*


*From the above code, I guess that this version supports model no. 61.
Hence, I build the kernel using the downloaded source.*


*While giving dpkg -i linux-4.2.0*.deb command,*


* I removed all the files (initrd, vmlinux,config, abi and Systmap) for
the current version. I also removed links from root /.*


*The execution of dpkg command was proper and it generated new files for
which the previous copies were removed.*



*I rebooted the system, still the same error is encountered.*


*Is there any step which is missed for kernel rebuilding?*

*Thanks*
Post by Michael Petlan
Hi,
Broadwell PMU support was added to linux kernel by commit
91f1b70582c62576f429cf78d53751c66677553d [1] --> you might
commit 91f1b70582c62576f429cf78d53751c66677553d
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
Hi,
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
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
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.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
Event Count % time counted
cpu_clk_unhalted 3,982,864 100.00
or using perf (linux-tools package), by
$ perf stat -e cycles 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 <
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
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)?
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.
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.
------------
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
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
operf ls
opreport
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 <
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
$ 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
dhara buch
2017-03-04 13:26:53 UTC
Permalink
Raw Message
Hello,

In continuity of my previous mail, I would like to add that, after getting
failure in rebuilding existing kernel , I downloaded source of latest
linux-4.10.1 also.

While trying to install it i encountered :

REPORTING_BUGS not found error:

Can you please help to solve this issue?

Thanking you,

Dhara Buch
Post by Michael Petlan
Hi,
Broadwell PMU support was added to linux kernel by commit
91f1b70582c62576f429cf78d53751c66677553d [1] --> you might
commit 91f1b70582c62576f429cf78d53751c66677553d
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
Hi,
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
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
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.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
Event Count % time counted
cpu_clk_unhalted 3,982,864 100.00
or using perf (linux-tools package), by
$ perf stat -e cycles 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 <
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
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)?
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.
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.
------------
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
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
operf ls
opreport
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 <
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
$ 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
Loading...