hi all,
----------------------------------------
ref-cycles event is specially to Intel core, but can still used in arm architecture
with the wrong return value with 3.10 stable. for instance:
perf stat -e ref-cycles sleep 1
Performance counter stats for 'sleep 1':
0 ref-cycles
1.002381916 seconds time elapsed
this patch fix the bug and make it return NOT SUPPORTED
distinctly.
In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file
and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0.
besides we can not simply cherry-pick.
Signed-off-by: Zhiqiang Zhang <[email protected]>
---
arch/arm/kernel/perf_event_v7.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 039cffb..c3d24aa 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -126,6 +126,7 @@ static const unsigned armv7_a8_perf_map[PERF_COUNT_HW_MAX] = {
[PERF_COUNT_HW_BUS_CYCLES] = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = ARMV7_A8_PERFCTR_STALL_ISIDE,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = HW_OP_UNSUPPORTED,
+ [PERF_COUNT_HW_REF_CPU_CYCLES] = HW_OP_UNSUPPORTED,
};
static const unsigned armv7_a8_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
@@ -250,6 +251,7 @@ static const unsigned armv7_a9_perf_map[PERF_COUNT_HW_MAX] = {
[PERF_COUNT_HW_BUS_CYCLES] = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = ARMV7_A9_PERFCTR_STALL_ICACHE,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = ARMV7_A9_PERFCTR_STALL_DISPATCH,
+ [PERF_COUNT_HW_REF_CPU_CYCLES] = HW_OP_UNSUPPORTED,
};
static const unsigned armv7_a9_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
@@ -374,6 +376,7 @@ static const unsigned armv7_a5_perf_map[PERF_COUNT_HW_MAX] = {
[PERF_COUNT_HW_BUS_CYCLES] = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = HW_OP_UNSUPPORTED,
+ [PERF_COUNT_HW_REF_CPU_CYCLES] = HW_OP_UNSUPPORTED,
};
static const unsigned armv7_a5_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
@@ -496,6 +499,7 @@ static const unsigned armv7_a15_perf_map[PERF_COUNT_HW_MAX] = {
[PERF_COUNT_HW_BUS_CYCLES] = ARMV7_PERFCTR_BUS_CYCLES,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = HW_OP_UNSUPPORTED,
+ [PERF_COUNT_HW_REF_CPU_CYCLES] = HW_OP_UNSUPPORTED,
};
static const unsigned armv7_a15_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
@@ -620,6 +624,7 @@ static const unsigned armv7_a7_perf_map[PERF_COUNT_HW_MAX] = {
[PERF_COUNT_HW_BUS_CYCLES] = ARMV7_PERFCTR_BUS_CYCLES,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = HW_OP_UNSUPPORTED,
+ [PERF_COUNT_HW_REF_CPU_CYCLES] = HW_OP_UNSUPPORTED,
};
static const unsigned armv7_a7_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
--
so, can we fix it in this way and put it into 3.10 stable repo.
On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote:
> hi all,
> ----------------------------------------
>
> ref-cycles event is specially to Intel core, but can still used in arm architecture
> with the wrong return value with 3.10 stable. for instance:
>
> perf stat -e ref-cycles sleep 1
>
> Performance counter stats for 'sleep 1':
>
> 0 ref-cycles
>
> 1.002381916 seconds time elapsed
>
> this patch fix the bug and make it return NOT SUPPORTED
> distinctly.
>
> In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file
> and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0.
> besides we can not simply cherry-pick.
I thought I saw Greg pick this up the other day?
Will
On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote:
> On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote:
> > hi all,
> > ----------------------------------------
> >
> > ref-cycles event is specially to Intel core, but can still used in arm architecture
> > with the wrong return value with 3.10 stable. for instance:
> >
> > perf stat -e ref-cycles sleep 1
> >
> > Performance counter stats for 'sleep 1':
> >
> > 0 ref-cycles
> >
> > 1.002381916 seconds time elapsed
> >
> > this patch fix the bug and make it return NOT SUPPORTED
> > distinctly.
> >
> > In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file
> > and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0.
> > besides we can not simply cherry-pick.
>
> I thought I saw Greg pick this up the other day?
Yes, it's in 3.16.4, did I do something wrong by accepting it?
confused,
greg k-h
On Wed, Oct 08, 2014 at 02:31:47PM +0100, [email protected] wrote:
> On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote:
> > On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote:
> > > hi all,
> > > ----------------------------------------
> > >
> > > ref-cycles event is specially to Intel core, but can still used in arm architecture
> > > with the wrong return value with 3.10 stable. for instance:
> > >
> > > perf stat -e ref-cycles sleep 1
> > >
> > > Performance counter stats for 'sleep 1':
> > >
> > > 0 ref-cycles
> > >
> > > 1.002381916 seconds time elapsed
> > >
> > > this patch fix the bug and make it return NOT SUPPORTED
> > > distinctly.
> > >
> > > In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file
> > > and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0.
> > > besides we can not simply cherry-pick.
> >
> > I thought I saw Greg pick this up the other day?
>
> Yes, it's in 3.16.4, did I do something wrong by accepting it?
Nah, it's a trivial patch that I struggle to get excited about. I'm just not
sure why it's being sent again, after you already accepted it.
Will
On 2014/10/8 21:38, Will Deacon wrote:
> On Wed, Oct 08, 2014 at 02:31:47PM +0100, [email protected] wrote:
>> On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote:
>>> On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote:
>>>> hi all,
>>>> ----------------------------------------
>>>>
>>>> ref-cycles event is specially to Intel core, but can still used in arm architecture
>>>> with the wrong return value with 3.10 stable. for instance:
>>>>
>>>> perf stat -e ref-cycles sleep 1
>>>>
>>>> Performance counter stats for 'sleep 1':
>>>>
>>>> 0 ref-cycles
>>>>
>>>> 1.002381916 seconds time elapsed
>>>>
>>>> this patch fix the bug and make it return NOT SUPPORTED
>>>> distinctly.
>>>>
>>>> In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file
>>>> and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0.
>>>> besides we can not simply cherry-pick.
>>>
>>> I thought I saw Greg pick this up the other day?
>>
>> Yes, it's in 3.16.4, did I do something wrong by accepting it?
>
> Nah, it's a trivial patch that I struggle to get excited about. I'm just not
> sure why it's being sent again, after you already accepted it.
Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into 3.10 or
do we have the plan?
On Thu, Oct 09, 2014 at 11:07:04AM +0800, zhangzhiqiang wrote:
> On 2014/10/8 21:38, Will Deacon wrote:
> > On Wed, Oct 08, 2014 at 02:31:47PM +0100, [email protected] wrote:
> >> On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote:
> >>> On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote:
> >>>> hi all,
> >>>> ----------------------------------------
> >>>>
> >>>> ref-cycles event is specially to Intel core, but can still used in arm architecture
> >>>> with the wrong return value with 3.10 stable. for instance:
> >>>>
> >>>> perf stat -e ref-cycles sleep 1
> >>>>
> >>>> Performance counter stats for 'sleep 1':
> >>>>
> >>>> 0 ref-cycles
> >>>>
> >>>> 1.002381916 seconds time elapsed
> >>>>
> >>>> this patch fix the bug and make it return NOT SUPPORTED
> >>>> distinctly.
> >>>>
> >>>> In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file
> >>>> and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0.
> >>>> besides we can not simply cherry-pick.
> >>>
> >>> I thought I saw Greg pick this up the other day?
> >>
> >> Yes, it's in 3.16.4, did I do something wrong by accepting it?
> >
> > Nah, it's a trivial patch that I struggle to get excited about. I'm just not
> > sure why it's being sent again, after you already accepted it.
>
> Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into 3.10 or
> do we have the plan?
Does it apply to 3.10-stable? Did you test it there and see if it
resolves your issue?
thanks,
greg k-h
On 2014/10/9 11:41, [email protected] wrote:
> On Thu, Oct 09, 2014 at 11:07:04AM +0800, zhangzhiqiang wrote:
>> On 2014/10/8 21:38, Will Deacon wrote:
>>> On Wed, Oct 08, 2014 at 02:31:47PM +0100, [email protected] wrote:
>>>> On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote:
>>>>> On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote:
>>>>>> hi all,
>>>>>> ----------------------------------------
>>>>>>
>>>>>> ref-cycles event is specially to Intel core, but can still used in arm architecture
>>>>>> with the wrong return value with 3.10 stable. for instance:
>>>>>>
>>>>>> perf stat -e ref-cycles sleep 1
>>>>>>
>>>>>> Performance counter stats for 'sleep 1':
>>>>>>
>>>>>> 0 ref-cycles
>>>>>>
>>>>>> 1.002381916 seconds time elapsed
>>>>>>
>>>>>> this patch fix the bug and make it return NOT SUPPORTED
>>>>>> distinctly.
>>>>>>
>>>>>> In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file
>>>>>> and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0.
>>>>>> besides we can not simply cherry-pick.
>>>>>
>>>>> I thought I saw Greg pick this up the other day?
>>>>
>>>> Yes, it's in 3.16.4, did I do something wrong by accepting it?
>>>
>>> Nah, it's a trivial patch that I struggle to get excited about. I'm just not
>>> sure why it's being sent again, after you already accepted it.
>>
>> Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into 3.10 or
>> do we have the plan?
>
> Does it apply to 3.10-stable? Did you test it there and see if it
> resolves your issue?
I have tested in 3.10.56, the bug is still existing and the patch is apply to 3.10-stable.
Follow is the result without/with this patch based on 3.10.56.
3.10.56 without the patch:
bash-4.2# perf stat -e ref-cycles sleep 1
Performance counter stats for 'sleep 1':
0 ref-cycles
1.002461500 seconds time elapsed
3.10.56 with the patch:
bash-4.2# perf stat -e ref-cycles sleep 1
Performance counter stats for 'sleep 1':
<not supported> ref-cycles
1.002385243 seconds time elapsed
Best wishes,
zhangzhiqiang
On Thu, Oct 09, 2014 at 03:13:00PM +0800, zhangzhiqiang wrote:
> On 2014/10/9 11:41, [email protected] wrote:
> > On Thu, Oct 09, 2014 at 11:07:04AM +0800, zhangzhiqiang wrote:
> >> On 2014/10/8 21:38, Will Deacon wrote:
> >>> On Wed, Oct 08, 2014 at 02:31:47PM +0100, [email protected] wrote:
> >>>> On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote:
> >>>>> On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote:
> >>>>>> hi all,
> >>>>>> ----------------------------------------
> >>>>>>
> >>>>>> ref-cycles event is specially to Intel core, but can still used in arm architecture
> >>>>>> with the wrong return value with 3.10 stable. for instance:
> >>>>>>
> >>>>>> perf stat -e ref-cycles sleep 1
> >>>>>>
> >>>>>> Performance counter stats for 'sleep 1':
> >>>>>>
> >>>>>> 0 ref-cycles
> >>>>>>
> >>>>>> 1.002381916 seconds time elapsed
> >>>>>>
> >>>>>> this patch fix the bug and make it return NOT SUPPORTED
> >>>>>> distinctly.
> >>>>>>
> >>>>>> In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file
> >>>>>> and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0.
> >>>>>> besides we can not simply cherry-pick.
> >>>>>
> >>>>> I thought I saw Greg pick this up the other day?
> >>>>
> >>>> Yes, it's in 3.16.4, did I do something wrong by accepting it?
> >>>
> >>> Nah, it's a trivial patch that I struggle to get excited about. I'm just not
> >>> sure why it's being sent again, after you already accepted it.
> >>
> >> Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into 3.10 or
> >> do we have the plan?
> >
> > Does it apply to 3.10-stable? Did you test it there and see if it
> > resolves your issue?
>
> I have tested in 3.10.56, the bug is still existing and the patch is apply to 3.10-stable.
> Follow is the result without/with this patch based on 3.10.56.
>
> 3.10.56 without the patch:
> bash-4.2# perf stat -e ref-cycles sleep 1
>
> Performance counter stats for 'sleep 1':
>
> 0 ref-cycles
>
> 1.002461500 seconds time elapsed
>
> 3.10.56 with the patch:
> bash-4.2# perf stat -e ref-cycles sleep 1
>
> Performance counter stats for 'sleep 1':
>
> <not supported> ref-cycles
>
> 1.002385243 seconds time elapsed
Given I have no idea what the patch even does, or is supposed to be
doing, I don't know how to answer this, except it looks like I shouldn't
be applying this to the 3.10-stable kernel series :)
sorry,
greg k-h