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

Reply via email to