From: "Yan, Zheng" <zheng.z.yan@linux.intel.com>
To: Stephane Eranian <eranian@google.com>
Cc: "Yan, Zheng" <zheng.z.yan@intel.com>,
a.p.zijlstra@chello.nl, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf: Fix intel shared extra msr allocation
Date: Tue, 05 Jun 2012 10:18:15 +0800 [thread overview]
Message-ID: <4FCD6C67.9050103@linux.intel.com> (raw)
In-Reply-To: <CABPqkBRA0Z-oZfSgdyurtW0=KUbuGJ+uFqiVKiwbt9Wpk1Ph7w@mail.gmail.com>
On 06/04/2012 09:12 PM, Stephane Eranian wrote:
> On Fri, Jun 1, 2012 at 4:11 PM, Yan, Zheng <zheng.z.yan@linux.intel.com> wrote:
>> On Fri, Jun 1, 2012 at 5:35 PM, Stephane Eranian <eranian@google.com> wrote:
>>> On Fri, Jun 1, 2012 at 5:20 AM, Yan, Zheng <zheng.z.yan@intel.com> wrote:
>>>> From: "Yan, Zheng" <zheng.z.yan@intel.com>
>>>>
>>>> intel_shared_reg_get/put_constraints() can be indirectly called
>>>> by validate_group(). In that case, they should avoid modifying
>>>> the perf_event date structure because the event can be already
>>>> in active state. Otherwise the shared extra msr's reference
>>>> count will be left in inconsistent state.
>>>>
>>> I understand the problem but I am wondering if you actually saw
>>> it in real life. The reason I am asking is because of the way
>>> validate_group() collects the events and how they are added
>>> to sibling_list. The new event is added at the tail. Thus it will
>>> come last, and will get to __intel_shared_reg_get_constraints()
>>> last, thus I am wondering if it can really modify the programming
>>> on the existing events.
>>
>> The real problem is from __intel_shared_reg_put_constraints(). it set
>> reg->alloc to 0 and decreases fake_cpuc->shared_regs->regs[reg->idx]'s
>> reference count. Later when deleting the event, put_constraints() will find
>> reg->alloc is 0 and it won't decrease the shared msr's reference count.
>>
>> Run 'perf stat --group -a -C 0 -e LLC-loads -e LLC-stores sleep 1" on
>> Nehalem can trigger the bug.
>>
> And what do you see in this particular example?
The offcore_rsp msr's reference count are left in inconsistent state. It means
we can only use the msr for LLC-loads event after that. Any other events that
require programming the offcore_rsp msr will fail.
>
> I'd like to see the results via libpfm4 and /perf_examples/syst_count:
> $ sudo ./syst_count -e offcore_response_0:dmnd_data_rd
> -eoffcore_response_0:dmnd_rfo -p -d 10 -c 0
>
This does not use the event group feature. do you mean
./syst_count -e offcore_response_0:dmnd_data_rd,offcore_response_0:dmnd_rfo -p -d 10 -c 0.
After apply my patch, the above command fails on Nehalem. Because there is no offcore_rsp1.
Regards
Yan, Zheng
next prev parent reply other threads:[~2012-06-05 2:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-01 3:20 [PATCH] perf: Fix intel shared extra msr allocation Yan, Zheng
2012-06-01 9:35 ` Stephane Eranian
2012-06-01 14:11 ` Yan, Zheng
2012-06-04 13:12 ` Stephane Eranian
2012-06-05 2:18 ` Yan, Zheng [this message]
2012-06-05 10:14 ` Peter Zijlstra
2012-06-05 10:21 ` Stephane Eranian
2012-06-05 10:27 ` Peter Zijlstra
2012-06-05 10:38 ` Stephane Eranian
2012-06-05 12:07 ` Peter Zijlstra
2012-06-05 12:39 ` Peter Zijlstra
2012-06-05 12:51 ` Stephane Eranian
2012-06-05 13:04 ` Peter Zijlstra
2012-06-05 13:30 ` [PATCH] perf, x86: Fix Intel shared extra MSR allocation Peter Zijlstra
2012-06-05 13:56 ` Peter Zijlstra
2012-06-05 21:26 ` Stephane Eranian
2012-06-06 1:00 ` Yan, Zheng
2012-06-06 15:57 ` [tip:perf/core] perf/x86: " tip-bot for Peter Zijlstra
2012-06-06 16:11 ` tip-bot for Peter Zijlstra
2012-06-05 13:31 ` [PATCH] perf: Fix intel shared extra msr allocation Stephane Eranian
2012-06-05 13:32 ` Peter Zijlstra
2012-06-05 13:38 ` Stephane Eranian
2012-06-05 13:47 ` Peter Zijlstra
2012-06-05 13:51 ` Stephane Eranian
2012-06-06 10:12 ` Stephane Eranian
2012-06-07 1:25 ` Yan, Zheng
2012-06-07 4:01 ` Yan, Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FCD6C67.9050103@linux.intel.com \
--to=zheng.z.yan@linux.intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zheng.z.yan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.