cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
Originally, the thresholds used in the cpuidle driver for Armada SOCs were temporarily chosen, leaving room for improvements.
This commit updates the thresholds for the Armada XP SOCs with values that positively impact performances:
without patch with patch vendor kernel - iperf localhost (gbit/sec) ~3.7 ~6.4 ~5.4 - ioping tmpfs (iops) ~163k ~206k ~179k - ioping tmpfs (mib/s) ~636 ~805 ~699
The idle power consumption is negatively impacted (proportionally less than the performance gain), and we are still performing better than the vendor kernel here:
without patch with patch vendor kernel - power consumption idle (W) ~2.4 ~3.2 ~4.4 - power consumption busy (W) ~8.6 ~8.3 ~8.6
There is still room for improvement regarding the value of these thresholds, they were chosen to mimic the vendor kernel.
This patch only impacts Armada XP SOCs and was tested on Online Labs C1 boards. A similar approach can be taken to improve the performances of the Armada 370 and Armada 38x SOCs.
Thanks a lot to Thomas Petazzoni, Gregory Clement and Willy Tarreau for the discussions and tips around this topic.
--- drivers/cpuidle/cpuidle-mvebu-v7.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/cpuidle/cpuidle-mvebu-v7.c +4 -4
@@ -50,17 +50,17 @@ static struct cpuidle_driver armadaxp_idle_driver = { .states[0] = ARM_CPUIDLE_WFI_STATE, .states[1] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 10, + .exit_latency = 100, .power_usage = 50, - .target_residency = 100, + .target_residency = 1000, .name = "MV CPU IDLE", .desc = "CPU power down", }, .states[2] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 100, + .exit_latency = 1000, .power_usage = 5, - .target_residency = 1000, + .target_residency = 10000, .flags = MVEBU_V7_FLAG_DEEP_IDLE, .name = "MV CPU DEEP IDLE", .desc = "CPU and L2 Fabric power down",
Signature · 1 line
2.1.4
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
Hi Sebastien,
Quoted 22 lines · s. rannou
Originally, the thresholds used in the cpuidle driver for Armada SOCs were temporarily chosen, leaving room for improvements.
This commit updates the thresholds for the Armada XP SOCs with values that positively impact performances:
without patch with patch vendor kernel - iperf localhost (gbit/sec) ~3.7 ~6.4 ~5.4 - ioping tmpfs (iops) ~163k ~206k ~179k - ioping tmpfs (mib/s) ~636 ~805 ~699The idle power consumption is negatively impacted (proportionally less than the performance gain), and we are still performing better than the vendor kernel here:
without patch with patch vendor kernel - power consumption idle (W) ~2.4 ~3.2 ~4.4 - power consumption busy (W) ~8.6 ~8.3 ~8.6There is still room for improvement regarding the value of these thresholds, they were chosen to mimic the vendor kernel.
Quoted 6 lines
This patch only impacts Armada XP SOCs and was tested on Online Labs C1 boards. A similar approach can be taken to improve the performances of the Armada 370 and Armada 38x SOCs.
Thanks a lot to Thomas Petazzoni, Gregory Clement and Willy Tarreau for the discussions and tips around this topic.
Thanks for your work and all the test you have done. As you mentioned there should be still room for improvement, but this patch is already a step in the good direction. So you can add my:
While this driver is related to mvebu SoCs, it is not part of the mvebu subsystem but of the PM subsystem and should be taken by its maintainers. I added them in copy as well as the pm list.
Daniel and Rafael,
if you didn't get the original email I can bounced if needed. I also wonder it it would worth applying it on the stable branch. What do you think about it?
Thanks,
Gregory
Quoted 33 lines
Signed-off-by Sebastien Rannou <[email protected]>--- drivers/cpuidle/cpuidle-mvebu-v7.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/cpuidle/cpuidle-mvebu-v7.c +4
-4@@ -50,17 +50,17 @@ static struct cpuidle_driver armadaxp_idle_driver = { .states[0] = ARM_CPUIDLE_WFI_STATE, .states[1] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 10, + .exit_latency = 100, .power_usage = 50, - .target_residency = 100, + .target_residency = 1000, .name = "MV CPU IDLE", .desc = "CPU power down", }, .states[2] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 100, + .exit_latency = 1000, .power_usage = 5, - .target_residency = 1000, + .target_residency = 10000, .flags = MVEBU_V7_FLAG_DEEP_IDLE, .name = "MV CPU DEEP IDLE", .desc = "CPU and L2 Fabric power down",
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
In reply to s. rannouQuoted 22 lines · s. rannou
Originally, the thresholds used in the cpuidle driver for Armada SOCs were temporarily chosen, leaving room for improvements.
This commit updates the thresholds for the Armada XP SOCs with values that positively impact performances:
without patch with patch vendor kernel - iperf localhost (gbit/sec) ~3.7 ~6.4 ~5.4 - ioping tmpfs (iops) ~163k ~206k ~179k - ioping tmpfs (mib/s) ~636 ~805 ~699The idle power consumption is negatively impacted (proportionally less than the performance gain), and we are still performing better than the vendor kernel here:
without patch with patch vendor kernel - power consumption idle (W) ~2.4 ~3.2 ~4.4 - power consumption busy (W) ~8.6 ~8.3 ~8.6There is still room for improvement regarding the value of these thresholds, they were chosen to mimic the vendor kernel.
Quoted 6 lines
This patch only impacts Armada XP SOCs and was tested on Online Labs C1 boards. A similar approach can be taken to improve the performances of the Armada 370 and Armada 38x SOCs.
Thanks a lot to Thomas Petazzoni, Gregory Clement and Willy Tarreau for the discussions and tips around this topic.
Hi Sebastien,
trying to tune the target residency and the exit latency is a good idea but you can have multiple results. If you increase the exit latency and the target residency, then the governor will choose a shallow state, thus improving the performance and degrading the power consumption. If you reduce the values, then the performance will degrade but the power saving will increase in an acceptable interval (until going to this state does not consume more energy).
If you have the possibility, I would suggest to apply the right methodology to find the right values by using the description in the wiki page [1]. If you can access to the energy values to enter / exit the state and the power consumed in each idle state, then you can mathematically compute the right values.
-- Daniel
[1]
https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/ComputingTargetResidency
Quoted 33 lines
Signed-off-by Sebastien Rannou <[email protected]>--- drivers/cpuidle/cpuidle-mvebu-v7.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/cpuidle/cpuidle-mvebu-v7.c +4
-4@@ -50,17 +50,17 @@ static struct cpuidle_driver armadaxp_idle_driver = { .states[0] = ARM_CPUIDLE_WFI_STATE, .states[1] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 10, + .exit_latency = 100, .power_usage = 50, - .target_residency = 100, + .target_residency = 1000, .name = "MV CPU IDLE", .desc = "CPU power down", }, .states[2] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 100, + .exit_latency = 1000, .power_usage = 5, - .target_residency = 1000, + .target_residency = 10000, .flags = MVEBU_V7_FLAG_DEEP_IDLE, .name = "MV CPU DEEP IDLE", .desc = "CPU and L2 Fabric power down",
Signature · 5 lines
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
Hi Daniel,
Thanks for the explanation and thanks for the link, I wish I had read it beforehand.
Quoted 5 lines · Daniel Lezcano
If you have the possibility, I would suggest to apply the right methodology to find the right values by using the description in the wiki page [1]. If you can access to the energy values to enter / exit the state and the power consumed in each idle state, then you can mathematically compute the right values.
Unfortunately I don't have access to the cost of transitions between states, nor do I have the time taken by each transition (which I could have used to infer the cost). I only have the power consumption of the different states.
I plan to find the adequate values by testing different combinations, but it is going to take some efforts before having a second patch. Since this patch already improves the situation by using the vendor's values, I think it is a move in the right direction, even though not being the most adequate values.
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
Quoted 12 lines · Sebastien Rannou
Hi Daniel,
Thanks for the explanation and thanks for the link, I wish I had read it beforehand.
Quoted 5 lines · Daniel Lezcano
If you have the possibility, I would suggest to apply the right methodology to find the right values by using the description in the wiki page [1]. If you can access to the energy values to enter / exit the state and the power consumed in each idle state, then you can mathematically compute the right values.
Quoted 4 lines
Unfortunately I don't have access to the cost of transitions between states, nor do I have the time taken by each transition (which I could have used to infer the cost). I only have the power consumption of the different states.
If you have the consumption for the different idle state + running, you have 60% of the data :)
Quoted 3 lines
I plan to find the adequate values by testing different combinations, but it is going to take some efforts before having a second patch.
You may waste your time because of the non deterministic prediction. Sometimes you will test with right values but wrong prediction and a cache 50% filled, sometimes you will test with wrong values and wrong prediction but a cache 20% filled etc ...
The only way to measure accurately is to identify the cpu power rails and measure the current peak when entering/exiting the different idle states with a device (oscilloscope, or whatever).
Quoted 3 lines
Since this patch already improves the situation by using the vendor's values, I think it is a move in the right direction, even though not being the most adequate values.
Just to clarify, vendor's values are from an out-of-tree which means it does not exist from an opensource pov and hence does not enter in the equation to pick the patch or not.
Regarding the values you measured for perf and power, it appears we have a improvement in terms of performance but with a power consumption degradation.
I am not against this patch, but I would like to have the ack from another Armada maintainer (Jason, Andrew or Sebastian) to be sure this trade-off is accepted.
Thanks
-- Daniel
Signature · 5 lines
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
In reply to s. rannouHello Daniel,
I know you suggested a more rigorous method of determining the exit latency and target residency times, but would it be nonetheless possible to apply this patch, which clearly improves performance a lot, and actually makes the code match the values used in the vendor kernel?
I also think this patch should be marked for stable, it fixes values introduced in commit b858fbc1919720f7f54360098ece03b383e961fa, and should therefore be backported all the way to v3.16.
Thanks a lot,
Thomas
Quoted 60 lines · s. rannou
Originally, the thresholds used in the cpuidle driver for Armada SOCs were temporarily chosen, leaving room for improvements.
This commit updates the thresholds for the Armada XP SOCs with values that positively impact performances:
without patch with patch vendor kernel - iperf localhost (gbit/sec) ~3.7 ~6.4 ~5.4 - ioping tmpfs (iops) ~163k ~206k ~179k - ioping tmpfs (mib/s) ~636 ~805 ~699The idle power consumption is negatively impacted (proportionally less than the performance gain), and we are still performing better than the vendor kernel here:
without patch with patch vendor kernel - power consumption idle (W) ~2.4 ~3.2 ~4.4 - power consumption busy (W) ~8.6 ~8.3 ~8.6There is still room for improvement regarding the value of these thresholds, they were chosen to mimic the vendor kernel.
This patch only impacts Armada XP SOCs and was tested on Online Labs C1 boards. A similar approach can be taken to improve the performances of the Armada 370 and Armada 38x SOCs.
Thanks a lot to Thomas Petazzoni, Gregory Clement and Willy Tarreau for the discussions and tips around this topic.
Signed-off-by Sebastien Rannou <[email protected]>--- drivers/cpuidle/cpuidle-mvebu-v7.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/cpuidle/cpuidle-mvebu-v7.c +4
-4@@ -50,17 +50,17 @@ static struct cpuidle_driver armadaxp_idle_driver = { .states[0] = ARM_CPUIDLE_WFI_STATE, .states[1] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 10, + .exit_latency = 100, .power_usage = 50, - .target_residency = 100, + .target_residency = 1000, .name = "MV CPU IDLE", .desc = "CPU power down", }, .states[2] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 100, + .exit_latency = 1000, .power_usage = 5, - .target_residency = 1000, + .target_residency = 10000, .flags = MVEBU_V7_FLAG_DEEP_IDLE, .name = "MV CPU DEEP IDLE", .desc = "CPU and L2 Fabric power down",
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
Quoted 10 lines · Thomas Petazzoni
Hello Daniel,
I know you suggested a more rigorous method of determining the exit latency and target residency times, but would it be nonetheless possible to apply this patch, which clearly improves performance a lot, and actually makes the code match the values used in the vendor kernel?
I also think this patch should be marked for stable, it fixes values introduced in commit
b858fbc1919720f7f54360098ece03b383e961fa, and should therefore be backported all the way to v3.16.
I don't have a problem to apply this patch. But I would like to have confirmation from one of the Armada maintainers the tradeoff is accepted (less energy saving for more performance).
Quoted 64 lines · s. rannou
Quoted 60 lines
Originally, the thresholds used in the cpuidle driver for Armada SOCs were temporarily chosen, leaving room for improvements.
This commit updates the thresholds for the Armada XP SOCs with values that positively impact performances:
without patch with patch vendor kernel - iperf localhost (gbit/sec) ~3.7 ~6.4 ~5.4 - ioping tmpfs (iops) ~163k ~206k ~179k - ioping tmpfs (mib/s) ~636 ~805 ~699The idle power consumption is negatively impacted (proportionally less than the performance gain), and we are still performing better than the vendor kernel here:
without patch with patch vendor kernel - power consumption idle (W) ~2.4 ~3.2 ~4.4 - power consumption busy (W) ~8.6 ~8.3 ~8.6There is still room for improvement regarding the value of these thresholds, they were chosen to mimic the vendor kernel.
This patch only impacts Armada XP SOCs and was tested on Online Labs C1 boards. A similar approach can be taken to improve the performances of the Armada 370 and Armada 38x SOCs.
Thanks a lot to Thomas Petazzoni, Gregory Clement and Willy Tarreau for the discussions and tips around this topic.
Signed-off-by Sebastien Rannou <[email protected]>--- drivers/cpuidle/cpuidle-mvebu-v7.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/cpuidle/cpuidle-mvebu-v7.c +4
-4@@ -50,17 +50,17 @@ static struct cpuidle_driver armadaxp_idle_driver = { .states[0] = ARM_CPUIDLE_WFI_STATE, .states[1] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 10, + .exit_latency = 100, .power_usage = 50, - .target_residency = 100, + .target_residency = 1000, .name = "MV CPU IDLE", .desc = "CPU power down", }, .states[2] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 100, + .exit_latency = 1000, .power_usage = 5, - .target_residency = 1000, + .target_residency = 10000, .flags = MVEBU_V7_FLAG_DEEP_IDLE, .name = "MV CPU DEEP IDLE", .desc = "CPU and L2 Fabric power down",
Signature · 5 lines
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
Quoted 8 lines · Daniel Lezcano
Quoted 7 lines · Thomas Petazzoni
Hello Daniel,
I know you suggested a more rigorous method of determining the exit latency and target residency times, but would it be nonetheless possible to apply this patch, which clearly improves performance a lot, and actually makes the code match the values used in the vendor kernel?
Quoted 7 lines
Quoted 3 lines
I also think this patch should be marked for stable, it fixes values introduced in commit
b858fbc1919720f7f54360098ece03b383e961fa, and should therefore be backported all the way to v3.16.I don't have a problem to apply this patch. But I would like to have confirmation from one of the Armada maintainers the tradeoff is accepted (less energy saving for more performance).
Hi Daniel
I believe Gregory has already acked this patch. Or do you want a explicit Acked-and-tradeoff-accepted-by:
Andrew
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
In reply to Daniel LezcanoLe 10 mars 2015 19:35:19 GMT+01:00, Daniel Lezcano <[email protected]> a ?crit :
Quoted 10 lines · Thomas Petazzoni
Quoted 5 lines
Hello Daniel,
I know you suggested a more rigorous method of determining the exit latency and target residency times, but would it be nonetheless possible to apply this patch, which clearly improves performance a
lot,
Quoted 1 line
and actually makes the code match the values used in the vendor
kernel?
Quoted 1 line
Quoted 8 lines
Quoted 3 lines
I also think this patch should be marked for stable, it fixes values introduced in commit
b858fbc1919720f7f54360098ece03b383e961fa, and should therefore be backported all the way to v3.16.I don't have a problem to apply this patch. But I would like to have confirmation from one of the Armada maintainers the tradeoff is accepted
(less energy saving for more performance).
Hi Daniel,
I already gave my acked- by for this patch, so for me this tradeoff is acceptable.
Gr?gory
Quoted 82 lines
Quoted 4 lines · s. rannou
Quoted 1 line
Originally, the thresholds used in the cpuidle driver for Armada
SOCs
Quoted 3 lines
Quoted 3 lines
were temporarily chosen, leaving room for improvements.
This commit updates the thresholds for the Armada XP SOCs with
values
Quoted 3 lines
Quoted 3 lines
that positively impact performances:
without patch with patch vendor
kernel
Quoted 5 lines
Quoted 5 lines
- iperf localhost (gbit/sec) ~3.7 ~6.4 ~5.4 - ioping tmpfs (iops) ~163k ~206k ~179k - ioping tmpfs (mib/s) ~636 ~805 ~699The idle power consumption is negatively impacted (proportionally
less
Quoted 4 lines
Quoted 4 lines
than the performance gain), and we are still performing better than the vendor kernel here:
without patch with patch vendor
kernel
Quoted 8 lines
Quoted 8 lines
- power consumption idle (W) ~2.4 ~3.2 ~4.4 - power consumption busy (W) ~8.6 ~8.3 ~8.6There is still room for improvement regarding the value of these thresholds, they were chosen to mimic the vendor kernel.
This patch only impacts Armada XP SOCs and was tested on Online Labs C1 boards. A similar approach can be taken to improve the
performances
Quoted 11 lines
Review
Quoted 11 lines
of the Armada 370 and Armada 38x SOCs.
Thanks a lot to Thomas Petazzoni, Gregory Clement and Willy Tarreau for the discussions and tips around this topic.
Signed-off-by Sebastien Rannou <[email protected]>--- drivers/cpuidle/cpuidle-mvebu-v7.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)(quoted diff) +0
-0
b/drivers/cpuidle/cpuidle-mvebu-v7.cQuoted 4 lines
drivers/cpuidle/cpuidle-mvebu-v7.c static struct cpuidle_driver
Quoted 4 lines
index 38e6861..3716a1f 100644
drivers/cpuidle/cpuidle-mvebu-v7.c +0
-0@@ -50,17 +50,17 @@ static struct cpuidle_driver
armadaxp_idle_driver= {Quoted 24 lines
Quoted 21 lines
drivers/cpuidle/cpuidle-mvebu-v7.c +4
-4.states[0] = ARM_CPUIDLE_WFI_STATE, .states[1] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 10, + .exit_latency = 100, .power_usage = 50, - .target_residency = 100, + .target_residency = 1000, .name = "MV CPU IDLE", .desc = "CPU power down", }, .states[2] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 100, + .exit_latency = 1000, .power_usage = 5, - .target_residency = 1000, + .target_residency = 10000, .flags = MVEBU_V7_FLAG_DEEP_IDLE, .name = "MV CPU DEEP IDLE", .desc = "CPU and L2 Fabric power down",Signature · 5 lines
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
Quoted 20 lines · Gregory CLEMENT
Le 10 mars 2015 19:35:19 GMT+01:00, Daniel Lezcano <[email protected]> a ?crit :
Quoted 10 lines · Thomas Petazzoni
Quoted 5 lines
Hello Daniel,
I know you suggested a more rigorous method of determining the exit latency and target residency times, but would it be nonetheless possible to apply this patch, which clearly improves performance a
lot,
Quoted 1 line
and actually makes the code match the values used in the vendor
kernel?
Quoted 1 line
Quoted 8 lines
Quoted 3 lines
I also think this patch should be marked for stable, it fixes values introduced in commit
b858fbc1919720f7f54360098ece03b383e961fa, and should therefore be backported all the way to v3.16.I don't have a problem to apply this patch. But I would like to have confirmation from one of the Armada maintainers the tradeoff is accepted
(less energy saving for more performance).
Quoted 4 lines
Hi Daniel,
I already gave my acked- by for this patch, so for me this tradeoff is acceptable.
Ah, Indeed.
Thanks.
-- Daniel
Quoted 83 lines
Quoted 81 lines
Quoted 3 lines · s. rannou
Quoted 1 line
Originally, the thresholds used in the cpuidle driver for Armada
SOCs
Quoted 3 lines
Quoted 3 lines
were temporarily chosen, leaving room for improvements.
This commit updates the thresholds for the Armada XP SOCs with
values
Quoted 3 lines
Quoted 3 lines
that positively impact performances:
without patch with patch vendor
kernel
Quoted 5 lines
Quoted 5 lines
- iperf localhost (gbit/sec) ~3.7 ~6.4 ~5.4 - ioping tmpfs (iops) ~163k ~206k ~179k - ioping tmpfs (mib/s) ~636 ~805 ~699The idle power consumption is negatively impacted (proportionally
less
Quoted 4 lines
Quoted 4 lines
than the performance gain), and we are still performing better than the vendor kernel here:
without patch with patch vendor
kernel
Quoted 8 lines
Quoted 8 lines
- power consumption idle (W) ~2.4 ~3.2 ~4.4 - power consumption busy (W) ~8.6 ~8.3 ~8.6There is still room for improvement regarding the value of these thresholds, they were chosen to mimic the vendor kernel.
This patch only impacts Armada XP SOCs and was tested on Online Labs C1 boards. A similar approach can be taken to improve the
performances
Quoted 11 lines
Review
Quoted 11 lines
of the Armada 370 and Armada 38x SOCs.
Thanks a lot to Thomas Petazzoni, Gregory Clement and Willy Tarreau for the discussions and tips around this topic.
Signed-off-by Sebastien Rannou <[email protected]>--- drivers/cpuidle/cpuidle-mvebu-v7.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)(quoted diff) +0
-0
b/drivers/cpuidle/cpuidle-mvebu-v7.cQuoted 4 lines
drivers/cpuidle/cpuidle-mvebu-v7.c static struct cpuidle_driver
Quoted 4 lines
index 38e6861..3716a1f 100644
drivers/cpuidle/cpuidle-mvebu-v7.c +0
-0@@ -50,17 +50,17 @@ static struct cpuidle_driver
armadaxp_idle_driver= {Quoted 13 lines
Quoted 13 lines
drivers/cpuidle/cpuidle-mvebu-v7.c +2
-2.states[0] = ARM_CPUIDLE_WFI_STATE, .states[1] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 10, + .exit_latency = 100, .power_usage = 50, - .target_residency = 100, + .target_residency = 1000, .name = "MV CPU IDLE", .desc = "CPU power down", }, .states[2] = { .enter = mvebu_v7_enter_idle,Quoted 11 lines
drivers/cpuidle/cpuidle-mvebu-v7.c static struct cpuidle_driver armadaxp_idle_driver = { · line 66
Quoted 8 lines
drivers/cpuidle/cpuidle-mvebu-v7.c +2
-2- .exit_latency = 100, + .exit_latency = 1000, .power_usage = 5, - .target_residency = 1000, + .target_residency = 10000, .flags = MVEBU_V7_FLAG_DEEP_IDLE, .name = "MV CPU DEEP IDLE", .desc = "CPU and L2 Fabric power down",--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCsFollow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Signature · 5 lines
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
PATCH 1/1 cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
In reply to Thomas PetazzoniQuoted 10 lines · Thomas Petazzoni
Hello Daniel,
I know you suggested a more rigorous method of determining the exit latency and target residency times, but would it be nonetheless possible to apply this patch, which clearly improves performance a lot, and actually makes the code match the values used in the vendor kernel?
I also think this patch should be marked for stable, it fixes values introduced in commit
b858fbc1919720f7f54360098ece03b383e961fa, and should therefore be backported all the way to v3.16.
I applied the patch for v4.1.
I will let you send later an mail to stable@ with the commit-id to ask backport. I don't want to put a stable@ tag in the patch as it does not enter in the stable kernel rules.
Thanks
-- Daniel
Quoted 64 lines · s. rannou
Quoted 60 lines
Originally, the thresholds used in the cpuidle driver for Armada SOCs were temporarily chosen, leaving room for improvements.
This commit updates the thresholds for the Armada XP SOCs with values that positively impact performances:
without patch with patch vendor kernel - iperf localhost (gbit/sec) ~3.7 ~6.4 ~5.4 - ioping tmpfs (iops) ~163k ~206k ~179k - ioping tmpfs (mib/s) ~636 ~805 ~699The idle power consumption is negatively impacted (proportionally less than the performance gain), and we are still performing better than the vendor kernel here:
without patch with patch vendor kernel - power consumption idle (W) ~2.4 ~3.2 ~4.4 - power consumption busy (W) ~8.6 ~8.3 ~8.6There is still room for improvement regarding the value of these thresholds, they were chosen to mimic the vendor kernel.
This patch only impacts Armada XP SOCs and was tested on Online Labs C1 boards. A similar approach can be taken to improve the performances of the Armada 370 and Armada 38x SOCs.
Thanks a lot to Thomas Petazzoni, Gregory Clement and Willy Tarreau for the discussions and tips around this topic.
Signed-off-by Sebastien Rannou <[email protected]>--- drivers/cpuidle/cpuidle-mvebu-v7.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/cpuidle/cpuidle-mvebu-v7.c +4
-4@@ -50,17 +50,17 @@ static struct cpuidle_driver armadaxp_idle_driver = { .states[0] = ARM_CPUIDLE_WFI_STATE, .states[1] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 10, + .exit_latency = 100, .power_usage = 50, - .target_residency = 100, + .target_residency = 1000, .name = "MV CPU IDLE", .desc = "CPU power down", }, .states[2] = { .enter = mvebu_v7_enter_idle, - .exit_latency = 100, + .exit_latency = 1000, .power_usage = 5, - .target_residency = 1000, + .target_residency = 10000, .flags = MVEBU_V7_FLAG_DEEP_IDLE, .name = "MV CPU DEEP IDLE", .desc = "CPU and L2 Fabric power down",
Signature · 5 lines
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog