* [PATCH V3] arm64: psci: Reduce waiting time for cpu_psci_cpu_kill()
@ 2019-10-18 11:24 Yunfeng Ye
2019-10-18 11:41 ` Mark Rutland
2019-10-18 11:45 ` Sudeep Holla
0 siblings, 2 replies; 5+ messages in thread
From: Yunfeng Ye @ 2019-10-18 11:24 UTC (permalink / raw)
To: catalin.marinas, will, kstewart, sudeep.holla, gregkh,
lorenzo.pieralisi, tglx, David.Laight, ard.biesheuvel
Cc: hushiyuan@huawei.com, linfeilong@huawei.com, wuyun.wu,
linux-kernel, linux-arm-kernel
In a case like suspend-to-disk, a large number of CPU cores need to be
shut down. At present, the CPU hotplug operation is serialised, and the
CPU cores can only be shut down one by one. In this process, if PSCI
affinity_info() does not return LEVEL_OFF quickly, cpu_psci_cpu_kill()
needs to wait for 10ms. If hundreds of CPU cores need to be shut down,
it will take a long time.
Normally, it is no need to wait 10ms in cpu_psci_cpu_kill(). So change
the wait interval from 10 ms to max 1 ms and use usleep_range() instead
of msleep() for more accurate schedule.
In addition, reduce the time interval will increase the messages output,
so remove the "Retry ..." message, instead, put the number of waiting
times to the sucessful message.
Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
---
v2 -> v3:
- update the comment
- remove the busy-wait logic, modify the loop logic and output message
v1 -> v2:
- use usleep_range() instead of udelay() after waiting for a while
arch/arm64/kernel/psci.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index c9f72b2665f1..00b8c0825a08 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -91,15 +91,14 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
* while it is dying. So, try again a few times.
*/
- for (i = 0; i < 10; i++) {
+ for (i = 0; i < 100; i++) {
err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
- pr_info("CPU%d killed.\n", cpu);
+ pr_info("CPU%d killed by waiting %d loops.\n", cpu, i);
return 0;
}
- msleep(10);
- pr_info("Retrying again to check for CPU kill\n");
+ usleep_range(100, 1000);
}
pr_warn("CPU%d may not have shut down cleanly (AFFINITY_INFO reports %d)\n",
--
2.7.4.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH V3] arm64: psci: Reduce waiting time for cpu_psci_cpu_kill()
2019-10-18 11:24 [PATCH V3] arm64: psci: Reduce waiting time for cpu_psci_cpu_kill() Yunfeng Ye
@ 2019-10-18 11:41 ` Mark Rutland
2019-10-18 12:22 ` Yunfeng Ye
2019-10-18 11:45 ` Sudeep Holla
1 sibling, 1 reply; 5+ messages in thread
From: Mark Rutland @ 2019-10-18 11:41 UTC (permalink / raw)
To: Yunfeng Ye
Cc: kstewart, lorenzo.pieralisi, ard.biesheuvel, hushiyuan@huawei.com,
catalin.marinas, sudeep.holla, linux-kernel,
linfeilong@huawei.com, David.Laight, gregkh, tglx, wuyun.wu, will,
linux-arm-kernel
On Fri, Oct 18, 2019 at 07:24:14PM +0800, Yunfeng Ye wrote:
> In a case like suspend-to-disk, a large number of CPU cores need to be
> shut down. At present, the CPU hotplug operation is serialised, and the
> CPU cores can only be shut down one by one. In this process, if PSCI
> affinity_info() does not return LEVEL_OFF quickly, cpu_psci_cpu_kill()
> needs to wait for 10ms. If hundreds of CPU cores need to be shut down,
> it will take a long time.
Do we have an idea of roughly how long a CPU _usually_ takes to
transition state?
i.e. are we _just_ missing the transition the first time we call
AFFINITY_INFO?
> Normally, it is no need to wait 10ms in cpu_psci_cpu_kill(). So change
> the wait interval from 10 ms to max 1 ms and use usleep_range() instead
> of msleep() for more accurate schedule.
>
> In addition, reduce the time interval will increase the messages output,
> so remove the "Retry ..." message, instead, put the number of waiting
> times to the sucessful message.
>
> Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
> ---
> v2 -> v3:
> - update the comment
> - remove the busy-wait logic, modify the loop logic and output message
>
> v1 -> v2:
> - use usleep_range() instead of udelay() after waiting for a while
>
> arch/arm64/kernel/psci.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index c9f72b2665f1..00b8c0825a08 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -91,15 +91,14 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
> * while it is dying. So, try again a few times.
> */
>
> - for (i = 0; i < 10; i++) {
> + for (i = 0; i < 100; i++) {
> err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
> if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
> - pr_info("CPU%d killed.\n", cpu);
> + pr_info("CPU%d killed by waiting %d loops.\n", cpu, i);
Could we please make that:
pr_info("CPU%d killed (polled %d times)\n", cpu, i + 1);
> return 0;
> }
>
> - msleep(10);
> - pr_info("Retrying again to check for CPU kill\n");
> + usleep_range(100, 1000);
Hmm, so now we'll wait somewhere between 10ms and 100ms before giving up
on a CPU depending on how long we actually sleep for each iteration of
the loop. That should be called out in the commit message.
That could matter for kdump when you have a large number of CPUs, as in
the worst case for 256 CPUs we've gone from ~2.6s to ~26s. But tbh in
that case I'm not sure I care that much...
In the majority of cases I'd hope AFFINITY_INFO would return OFF after
an iteration or two.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH V3] arm64: psci: Reduce waiting time for cpu_psci_cpu_kill()
2019-10-18 11:24 [PATCH V3] arm64: psci: Reduce waiting time for cpu_psci_cpu_kill() Yunfeng Ye
2019-10-18 11:41 ` Mark Rutland
@ 2019-10-18 11:45 ` Sudeep Holla
2019-10-18 12:03 ` Yunfeng Ye
1 sibling, 1 reply; 5+ messages in thread
From: Sudeep Holla @ 2019-10-18 11:45 UTC (permalink / raw)
To: Yunfeng Ye
Cc: kstewart, lorenzo.pieralisi, ard.biesheuvel, hushiyuan@huawei.com,
catalin.marinas, linux-kernel, linfeilong@huawei.com,
David.Laight, gregkh, tglx, wuyun.wu, will, linux-arm-kernel
On Fri, Oct 18, 2019 at 07:24:14PM +0800, Yunfeng Ye wrote:
> In a case like suspend-to-disk, a large number of CPU cores need to be
Add suspend-to-ram also to list, i.e.
"In case like suspend-to-disk and suspend-to-ram, a large number..."
> shut down. At present, the CPU hotplug operation is serialised, and the
> CPU cores can only be shut down one by one. In this process, if PSCI
> affinity_info() does not return LEVEL_OFF quickly, cpu_psci_cpu_kill()
> needs to wait for 10ms. If hundreds of CPU cores need to be shut down,
> it will take a long time.
>
> Normally, it is no need to wait 10ms in cpu_psci_cpu_kill(). So change
s/it is/there is/
> the wait interval from 10 ms to max 1 ms and use usleep_range() instead
> of msleep() for more accurate schedule.
>
s/for more accurate schedule/for more accurate timer/
> In addition, reduce the time interval will increase the messages output,
s/reduce/reducing/
> so remove the "Retry ..." message, instead, put the number of waiting
> times to the sucessful message.
>
> Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
> ---
> v2 -> v3:
> - update the comment
> - remove the busy-wait logic, modify the loop logic and output message
>
> v1 -> v2:
> - use usleep_range() instead of udelay() after waiting for a while
>
> arch/arm64/kernel/psci.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index c9f72b2665f1..00b8c0825a08 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -91,15 +91,14 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
> * while it is dying. So, try again a few times.
> */
>
> - for (i = 0; i < 10; i++) {
> + for (i = 0; i < 100; i++) {
> err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
> if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
> - pr_info("CPU%d killed.\n", cpu);
> + pr_info("CPU%d killed by waiting %d loops.\n", cpu, i);
> return 0;
> }
>
> - msleep(10);
> - pr_info("Retrying again to check for CPU kill\n");
> + usleep_range(100, 1000);
Since usleep_range can return anytime between 100us to 1ms, does it make
sense to check for (time_before(jiffies, timeout)) you had in v2 ?
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH V3] arm64: psci: Reduce waiting time for cpu_psci_cpu_kill()
2019-10-18 11:45 ` Sudeep Holla
@ 2019-10-18 12:03 ` Yunfeng Ye
0 siblings, 0 replies; 5+ messages in thread
From: Yunfeng Ye @ 2019-10-18 12:03 UTC (permalink / raw)
To: Sudeep Holla
Cc: kstewart, lorenzo.pieralisi, ard.biesheuvel, hushiyuan@huawei.com,
catalin.marinas, linux-kernel, linfeilong@huawei.com,
David.Laight, gregkh, tglx, wuyun.wu, will, linux-arm-kernel
On 2019/10/18 19:45, Sudeep Holla wrote:
> On Fri, Oct 18, 2019 at 07:24:14PM +0800, Yunfeng Ye wrote:
>> In a case like suspend-to-disk, a large number of CPU cores need to be
>
> Add suspend-to-ram also to list, i.e.
> "In case like suspend-to-disk and suspend-to-ram, a large number..."
>
ok, thanks.
>> shut down. At present, the CPU hotplug operation is serialised, and the
>> CPU cores can only be shut down one by one. In this process, if PSCI
>> affinity_info() does not return LEVEL_OFF quickly, cpu_psci_cpu_kill()
>> needs to wait for 10ms. If hundreds of CPU cores need to be shut down,
>> it will take a long time.
>>
>> Normally, it is no need to wait 10ms in cpu_psci_cpu_kill(). So change
>
> s/it is/there is/
>
ok, thanks.
>> the wait interval from 10 ms to max 1 ms and use usleep_range() instead
>> of msleep() for more accurate schedule.
>>
>
> s/for more accurate schedule/for more accurate timer/
>
ok, thanks.
>> In addition, reduce the time interval will increase the messages output,
>
> s/reduce/reducing/
>
ok, thanks.
>> so remove the "Retry ..." message, instead, put the number of waiting
>> times to the sucessful message.
>>
>> Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
>> ---
>> v2 -> v3:
>> - update the comment
>> - remove the busy-wait logic, modify the loop logic and output message
>>
>> v1 -> v2:
>> - use usleep_range() instead of udelay() after waiting for a while
>>
>> arch/arm64/kernel/psci.c | 7 +++----
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
>> index c9f72b2665f1..00b8c0825a08 100644
>> --- a/arch/arm64/kernel/psci.c
>> +++ b/arch/arm64/kernel/psci.c
>> @@ -91,15 +91,14 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
>> * while it is dying. So, try again a few times.
>> */
>>
>> - for (i = 0; i < 10; i++) {
>> + for (i = 0; i < 100; i++) {
>> err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
>> if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
>> - pr_info("CPU%d killed.\n", cpu);
>> + pr_info("CPU%d killed by waiting %d loops.\n", cpu, i);
>> return 0;
>> }
>>
>> - msleep(10);
>> - pr_info("Retrying again to check for CPU kill\n");
>> + usleep_range(100, 1000);
>
> Since usleep_range can return anytime between 100us to 1ms, does it make
> sense to check for (time_before(jiffies, timeout)) you had in v2 ?
>
ok, if using (time_before(jiffies, timeout)), the output message change to print
waiting xxx jiffies ? or still print the number of loops?
> --
> Regards,
> Sudeep
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH V3] arm64: psci: Reduce waiting time for cpu_psci_cpu_kill()
2019-10-18 11:41 ` Mark Rutland
@ 2019-10-18 12:22 ` Yunfeng Ye
0 siblings, 0 replies; 5+ messages in thread
From: Yunfeng Ye @ 2019-10-18 12:22 UTC (permalink / raw)
To: Mark Rutland
Cc: kstewart, lorenzo.pieralisi, ard.biesheuvel, hushiyuan@huawei.com,
catalin.marinas, sudeep.holla, linux-kernel,
linfeilong@huawei.com, David.Laight, gregkh, tglx, wuyun.wu, will,
linux-arm-kernel
On 2019/10/18 19:41, Mark Rutland wrote:
> On Fri, Oct 18, 2019 at 07:24:14PM +0800, Yunfeng Ye wrote:
>> In a case like suspend-to-disk, a large number of CPU cores need to be
>> shut down. At present, the CPU hotplug operation is serialised, and the
>> CPU cores can only be shut down one by one. In this process, if PSCI
>> affinity_info() does not return LEVEL_OFF quickly, cpu_psci_cpu_kill()
>> needs to wait for 10ms. If hundreds of CPU cores need to be shut down,
>> it will take a long time.
>
> Do we have an idea of roughly how long a CPU _usually_ takes to
> transition state?
>
> i.e. are we _just_ missing the transition the first time we call
> AFFINITY_INFO?
>
we have test that in most case is less than 1ms, 50us-500us. the time not
only include hardware state transition, but also include flush caches in BIOS.
and flush caches operation is time-consuming.
>> Normally, it is no need to wait 10ms in cpu_psci_cpu_kill(). So change
>> the wait interval from 10 ms to max 1 ms and use usleep_range() instead
>> of msleep() for more accurate schedule.
>>
>> In addition, reduce the time interval will increase the messages output,
>> so remove the "Retry ..." message, instead, put the number of waiting
>> times to the sucessful message.
>>
>> Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
>> ---
>> v2 -> v3:
>> - update the comment
>> - remove the busy-wait logic, modify the loop logic and output message
>>
>> v1 -> v2:
>> - use usleep_range() instead of udelay() after waiting for a while
>>
>> arch/arm64/kernel/psci.c | 7 +++----
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
>> index c9f72b2665f1..00b8c0825a08 100644
>> --- a/arch/arm64/kernel/psci.c
>> +++ b/arch/arm64/kernel/psci.c
>> @@ -91,15 +91,14 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
>> * while it is dying. So, try again a few times.
>> */
>>
>> - for (i = 0; i < 10; i++) {
>> + for (i = 0; i < 100; i++) {
>> err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
>> if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
>> - pr_info("CPU%d killed.\n", cpu);
>> + pr_info("CPU%d killed by waiting %d loops.\n", cpu, i);
>
> Could we please make that:
>
> pr_info("CPU%d killed (polled %d times)\n", cpu, i + 1);
>
ok, thanks.
>
>
>> return 0;
>> }
>>
>> - msleep(10);
>> - pr_info("Retrying again to check for CPU kill\n");
>> + usleep_range(100, 1000);
>
> Hmm, so now we'll wait somewhere between 10ms and 100ms before giving up
> on a CPU depending on how long we actually sleep for each iteration of
> the loop. That should be called out in the commit message.
>
> That could matter for kdump when you have a large number of CPUs, as in
> the worst case for 256 CPUs we've gone from ~2.6s to ~26s. But tbh in
> that case I'm not sure I care that much...
>
> In the majority of cases I'd hope AFFINITY_INFO would return OFF after
> an iteration or two.
>
Normally it will no need so much time.
> Thanks,
> Mark.
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-10-18 12:23 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-18 11:24 [PATCH V3] arm64: psci: Reduce waiting time for cpu_psci_cpu_kill() Yunfeng Ye
2019-10-18 11:41 ` Mark Rutland
2019-10-18 12:22 ` Yunfeng Ye
2019-10-18 11:45 ` Sudeep Holla
2019-10-18 12:03 ` Yunfeng Ye
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).