Re: Regarding vmlinux file for opcontrol --init
dhara buch <[email protected]>
| Newsgroups | gmane.linux.oprofile |
|---|---|
| Message-ID | <CA+ALRJWDZuHazPfVCvTg+bucFbC983hisiDRo_N-ojkgwZordg@mail.gmail.com> |
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*
On Thu, Mar 2, 2017 at 10:19 PM, Michael Petlan <[email protected]> wrote:
> 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