Skip to contentSkip to conversation

arm: armv7: perf: fix armv7 ref-cycles error

PATCH In review zhangzhiqiang 3 participants 8 messages Oct 8, 2014 – Oct 9, 2014

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 arm: armv7: perf: fix armv7 ref-cycles error

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.

---
 arch/arm/kernel/perf_event_v7.c | 5 +++++
 1 file changed, 5 insertions(+)
arch/arm/kernel/perf_event_v7.c +5 -0
index 039cffb..c3d24aa 100644
@@ -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.

#1 lore raw
Quoted 12 lines · zhangzhiqiang

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

Quoted 8 lines
       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

#2 lore raw
Quoted 15 lines · Will Deacon
Quoted 14 lines · zhangzhiqiang

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
Quoted 8 lines
Quoted 6 lines

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

#3 lore raw
Quoted 19 lines · gregkh at linuxfoundation.org
Quoted 18 lines · Will Deacon
Quoted 17 lines · zhangzhiqiang

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.

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

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

#4 lore raw
Quoted 24 lines · Will Deacon
Quoted 23 lines · gregkh at linuxfoundation.org
Quoted 22 lines · Will Deacon
Quoted 20 lines · zhangzhiqiang

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.

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

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?

#5 lore raw
Quoted 27 lines · zhangzhiqiang
Quoted 26 lines · Will Deacon
Quoted 25 lines · gregkh at linuxfoundation.org
Quoted 23 lines · Will Deacon
Quoted 12 lines · zhangzhiqiang

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

Quoted 8 lines
       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?

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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

#6 lore raw
Quoted 30 lines · gregkh at linuxfoundation.org
Quoted 29 lines · zhangzhiqiang
Quoted 28 lines · Will Deacon
Quoted 26 lines · gregkh at linuxfoundation.org
Quoted 15 lines · Will Deacon
Quoted 14 lines · zhangzhiqiang

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
Quoted 8 lines
Quoted 6 lines

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?

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

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

#7 lore raw
Quoted 52 lines · zhangzhiqiang
Quoted 30 lines · gregkh at linuxfoundation.org
Quoted 29 lines · zhangzhiqiang
Quoted 28 lines · Will Deacon
Quoted 26 lines · gregkh at linuxfoundation.org
Quoted 15 lines · Will Deacon
Quoted 14 lines · zhangzhiqiang

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
Quoted 8 lines
Quoted 6 lines

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?

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

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
Quoted 8 lines

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