From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
To: Lan Tianyu <tianyu.lan@intel.com>,
peterz@infradead.org, mingo@kernel.org, srivatsa@mit.edu,
akpm@linux-foundation.org, laijs@cn.fujitsu.com,
toshi.kani@hp.com, todd.e.brandt@linux.intel.com,
wangyun@linux.vnet.ibm.com, ego@linux.vnet.ibm.com,
fabf@skynet.be, linux@arm.linux.org.uk
Cc: oleg@redhat.com, srivatsa.bhat@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V2] PM/CPU: Parallel enalbing nonboot cpus with resume devices
Date: Sat, 30 Aug 2014 02:22:10 +0200 [thread overview]
Message-ID: <54011932.4060405@intel.com> (raw)
In-Reply-To: <53FFF642.7010909@intel.com>
On 8/29/2014 5:40 AM, Lan Tianyu wrote:
> On 2014年08月22日 16:33, Lan Tianyu wrote:
>> In the current world, all nonboot cpus are enabled serially during system
>> resume. System resume sequence is that boot cpu enables nonboot cpu one by
>> one and then resume devices. Before resuming devices, there are few tasks
>> assigned to nonboot cpus after they are brought up. This waste cpu usage.
>>
>> To accelerate S3, this patches allows boot cpu to go forward to resume
>> devices after bringing up one nonboot cpu. The nonboot cpu will be in
>> charge of bringing up other cpus. This makes enabling cpu2~x parallel
>> with resuming devices.
>>
>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>> ---
>> Change since V1:
>> Remove PM_PARALLEL_CPU_UP_FOR_SUSPEND kernel config and make
>> paralleling cpu as default behaviour. Add error handling for
>> failure of the first frozen cpu online.
>>
>> So far, I just tested the patch on the Intel machines. It's better
>> to test it on the others Arch platforms. Appreciate a lot if some
>> one can help test it.
>>
> Hi All:
> Any comments on this patch? Thanks.
You need to ensure that the async thing completes before
cpufreq_resume() or bad things will happen I think.
>> kernel/cpu.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++-----------
>> 1 file changed, 58 insertions(+), 12 deletions(-)
>>
>> diff --git a/kernel/cpu.c b/kernel/cpu.c
>> index a343bde..9bc8497 100644
>> --- a/kernel/cpu.c
>> +++ b/kernel/cpu.c
>> @@ -551,8 +551,42 @@ void __weak arch_enable_nonboot_cpus_end(void)
>> {
>> }
>>
>> +static int _cpu_up_with_trace(int cpu)
Better name?
>> +{
>> + int error;
>> +
>> + trace_suspend_resume(TPS("CPU_ON"), cpu, true);
>> + error = _cpu_up(cpu, 1);
>> + trace_suspend_resume(TPS("CPU_ON"), cpu, false);
>> + if (error) {
>> + pr_warn("Error taking CPU%d up: %d\n", cpu, error);
>> + return error;
>> + }
>> +
>> + pr_info("CPU%d is up\n", cpu);
>> + return 0;
>> +}
>> +
>> +static int async_enable_nonboot_cpus(void *data)
>> +{
>> + int cpu;
>> +
>> + cpu_maps_update_begin();
>> + arch_enable_nonboot_cpus_begin();
Shouldn't you call this before trying to bring up the first one?
>> +
>> + for_each_cpu(cpu, frozen_cpus) {
>> + _cpu_up_with_trace(cpu);
>> + }
>> +
>> + arch_enable_nonboot_cpus_end();
>> + cpumask_clear(frozen_cpus);
>> + cpu_maps_update_done();
>> + return 0;
>> +}
>> +
>> void __ref enable_nonboot_cpus(void)
>> {
>> + struct task_struct *tsk;
>> int cpu, error;
>>
>> /* Allow everyone to use the CPU hotplug again */
>> @@ -563,22 +597,34 @@ void __ref enable_nonboot_cpus(void)
>>
>> pr_info("Enabling non-boot CPUs ...\n");
>>
>> - arch_enable_nonboot_cpus_begin();
>> + cpu = cpumask_first(frozen_cpus);
>> + cpumask_clear_cpu(cpu, frozen_cpus);
>>
>> - for_each_cpu(cpu, frozen_cpus) {
>> - trace_suspend_resume(TPS("CPU_ON"), cpu, true);
>> - error = _cpu_up(cpu, 1);
>> - trace_suspend_resume(TPS("CPU_ON"), cpu, false);
>> - if (!error) {
>> - pr_info("CPU%d is up\n", cpu);
>> - continue;
>> + error = _cpu_up_with_trace(cpu);
>> + if (cpumask_empty(frozen_cpus))
>> + goto out;
>> +
>> + if (error) {
>> + /*
>> + * If fail to bring up the first frozen cpus,
>> + * enable the rest frozen cpus on the boot cpu.
>> + */
>> + arch_enable_nonboot_cpus_begin();
>> + for_each_cpu(cpu, frozen_cpus) {
>> + _cpu_up_with_trace(cpu);
>> }
>> - pr_warn("Error taking CPU%d up: %d\n", cpu, error);
>> - }
>> + arch_enable_nonboot_cpus_end();
>>
>> - arch_enable_nonboot_cpus_end();
>> + } else {
>> + tsk = kthread_create_on_cpu(async_enable_nonboot_cpus,
>> + NULL, cpu, "async-enable-nonboot-cpus");
Does it really need to run on the other CPU? If the idea is to avoid
waiting mostly, the async thread can start running on the boot CPU just
fine I suppose.
>> + if (IS_ERR(tsk)) {
>> + pr_err("Failed to create async enable nonboot cpus thread.\n");
>> + goto out;
>> + }
>>
>> - cpumask_clear(frozen_cpus);
>> + kthread_unpark(tsk);
>> + }
>> out:
>> cpu_maps_update_done();
>> }
>>
>
Rafael
next prev parent reply other threads:[~2014-08-30 0:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-22 8:33 [RFC PATCH V2] PM/CPU: Parallel enalbing nonboot cpus with resume devices Lan Tianyu
2014-08-29 3:40 ` Lan Tianyu
2014-08-30 0:22 ` Rafael J. Wysocki [this message]
2014-09-03 8:51 ` Lan Tianyu
2014-09-17 9:03 ` Gautham R Shenoy
2014-09-18 8:36 ` Lan Tianyu
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=54011932.4060405@intel.com \
--to=rafael.j.wysocki@intel.com \
--cc=akpm@linux-foundation.org \
--cc=ego@linux.vnet.ibm.com \
--cc=fabf@skynet.be \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=srivatsa@mit.edu \
--cc=tianyu.lan@intel.com \
--cc=todd.e.brandt@linux.intel.com \
--cc=toshi.kani@hp.com \
--cc=wangyun@linux.vnet.ibm.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 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).