Yes, the counters are working fine now. Thanks again. :)
On Wed, Sep 10, 2014 at 2:46 PM, Bhavishya Goel <bhavishya.g...@gmail.com>
wrote:
> Thanks a ton. I will try it out and get back with the results.
>
> On Wed, Sep 10, 2014 at 2:42 PM, Stephane Eranian <eran...@googlemail.com>
> wrote:
>
>> ok, then it is easy.
>>
>> Do you have your kernel sources?
>>
>> If so, edit: arch/x86/kernel/cpu/perf_event_intel.c
>> locate : static struct event_constraint intel_ivb_event_constraints[]
>> __read_mostly =
>>
>> And remove the following lines AND ONLY THE following lines. The
>> EVENT_CONSTRAINT_END must remain.Then recompile your kernel, install the
>> kernel and reboot.
>> You will have access to the MEM_* and they are not broken with HT off.
>>
>> /*
>> * ErrataEVENT_CONSTRAINT_END BV98 -- MEM_*_RETIRED events can
>> leak between counters of SMT
>> * siblings; disable these events because they can corrupt
>> unrelated
>> * counters.
>> */
>> INTEL_EVENT_CONSTRAINT(0xd0, 0x0), /* MEM_UOPS_RETIRED.* */
>> INTEL_EVENT_CONSTRAINT(0xd1, 0x0), /* MEM_LOAD_UOPS_RETIRED.* */
>> INTEL_EVENT_CONSTRAINT(0xd2, 0x0), /*
>> MEM_LOAD_UOPS_LLC_HIT_RETIRED.* */
>> INTEL_EVENT_CONSTRAINT(0xd3, 0x0), /*
>> MEM_LOAD_UOPS_LLC_MISS_RETIRED.* */
>>
>>
>> On Wed, Sep 10, 2014 at 5:39 AM, Bhavishya Goel <bhavishya.g...@gmail.com
>> > wrote:
>>
>>> The HT is already turned off.
>>>
>>> On Wed, Sep 10, 2014 at 2:28 PM, Stephane Eranian <
>>> eran...@googlemail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 10, 2014 at 5:19 AM, Bhavishya Goel <
>>>> bhavishya.g...@gmail.com> wrote:
>>>>
>>>>> Oh, ok. :)
>>>>>
>>>>> Can you instruct me on how to apply the workaround?
>>>>>
>>>>> The easiest is to run your system with HT off. Can you do that?
>>>>
>>>>
>>>>> On Tue, Sep 9, 2014 at 4:18 PM, Stephane Eranian <
>>>>> eran...@googlemail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Sep 6, 2014 at 5:49 PM, Bhavishya Goel <
>>>>>> bhavishya.g...@gmail.com> wrote:
>>>>>>
>>>>>>> By the way, I have similar problems with PERF_COUNT_HW_CACHE_L1D
>>>>>>> event. Will the kernel workaround fix this event too?
>>>>>>>
>>>>>>> This is because this event maps to MEM_UOPS_REITRED (code 0xd0)
>>>>>> which is one of the broken events.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Thu, Sep 4, 2014 at 5:12 PM, Bhavishya Goel <
>>>>>>> bhavishya.g...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks Stephane. Yes, it would be very helpful if you can guide me
>>>>>>>> how to apply the workaround.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Sep 4, 2014 at 4:44 PM, Stephane Eranian <
>>>>>>>> eran...@googlemail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Sep 4, 2014 at 12:34 PM, Bhavishya Goel <
>>>>>>>>> bhavishya.g...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I am facing a problem in counting MEM_UOPS_RETIRED event on Ivy
>>>>>>>>>> Bridge. I am trying to use it with the *task* command and I get
>>>>>>>>>> following error:
>>>>>>>>>>
>>>>>>>>>> $> task -i -e MEM_UOPS_RETIRED:ALL_LOADS ls
>>>>>>>>>> task: cannot attach event0 MEM_UOPS_RETIRED:ALL_LOADS: Invalid
>>>>>>>>>> argument.
>>>>>>>>>>
>>>>>>>>>> I am facing similar problem for all the events that have dual
>>>>>>>>>> names in the output of *showevtinfo* and one of them is marked
>>>>>>>>>> "deprecated":
>>>>>>>>>> MEM_LOAD_LLC_HIT_RETIRED/MEM_LOAD_UOPS_LLC_HIT_RETIRED,
>>>>>>>>>> MEM_LOAD_RETIRED/MEM_LOAD_UOPS_RETIRED.
>>>>>>>>>> I have tried using both deprecated and recommended names.
>>>>>>>>>>
>>>>>>>>>> What am I doing wrong?
>>>>>>>>>>
>>>>>>>>>> Nothing wrong.
>>>>>>>>>
>>>>>>>>> It is just that those events are broken on IvyBridge. The kernel
>>>>>>>>> decided to blacklist them to prevent returning
>>>>>>>>> potentially bogus counts. Event 0xd0, 0xd1, 0xd2 are broken on
>>>>>>>>> Sandy Bridge, IvyBridge, Haswell. But the
>>>>>>>>> kernel only blacklisted them on IvyBridge.
>>>>>>>>>
>>>>>>>>> The bug is present only when you have Hyperthreading enabled. If
>>>>>>>>> you measure event 0xd0 in counter 0
>>>>>>>>> on HT0 then it corrupts whatever event is measured in counter0 HT1.
>>>>>>>>>
>>>>>>>>> We posted a kernel workaround to the Linux kernel mailing a couple
>>>>>>>>> of months back. It is not into mainline
>>>>>>>>> yet.
>>>>>>>>>
>>>>>>>>> I can help you workaround the problem is you are willing to
>>>>>>>>> rebuild your own kernel.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Bhavi
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ಠ_ಠ
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Slashdot TV.
>>>>>>>>>> Video for Nerds. Stuff that matters.
>>>>>>>>>> http://tv.slashdot.org/
>>>>>>>>>> _______________________________________________
>>>>>>>>>> perfmon2-devel mailing list
>>>>>>>>>> perfmon2-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ಠ_ಠ
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ಠ_ಠ
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ಠ_ಠ
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> ಠ_ಠ
>>>
>>
>>
>
>
> --
> ಠ_ಠ
>
--
ಠ_ಠ
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
