From: Michael Wang <wangyun@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
tglx@linutronix.de, peterz@infradead.org,
paulmck@linux.vnet.ibm.com, rusty@rustcorp.com.au,
mingo@kernel.org, namhyung@kernel.org,
vincent.guittot@linaro.org, sbw@mit.edu, tj@kernel.org,
amit.kucheria@linaro.org, rostedt@goodmis.org, rjw@sisk.pl,
xiaoguangrong@linux.vnet.ibm.com, nikunj@linux.vnet.ibm.com,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 01/10] CPU hotplug: Introduce "stable" cpu online mask, for atomic hotplug readers
Date: Wed, 05 Dec 2012 11:28:50 +0800 [thread overview]
Message-ID: <50BEBF72.80906@linux.vnet.ibm.com> (raw)
In-Reply-To: <50BEB7C4.9080906@linux.vnet.ibm.com>
On 12/05/2012 10:56 AM, Michael Wang wrote:
[...]
>>
>> I wonder about the cpu-online case. A typical caller might want to do:
>>
>>
>> /*
>> * Set each online CPU's "foo" to "bar"
>> */
>>
>> int global_bar;
>>
>> void set_cpu_foo(int bar)
>> {
>> get_online_cpus_stable_atomic();
>> global_bar = bar;
>> for_each_online_cpu_stable()
>> cpu->foo = bar;
>> put_online_cpus_stable_atomic()
>> }
>>
>> void_cpu_online_notifier_handler(void)
>> {
>> cpu->foo = global_bar;
>> }
Oh, forgive me for misunderstanding your question :(
In this case, we have to prevent hotplug happen, not just ensure the
online mask is correct.
Hmm..., we need more consideration.
Regards,
Michael Wang
>>
>> And I think that set_cpu_foo() would be buggy, because a CPU could come
>> online before global_bar was altered, and that newly-online CPU would
>> pick up the old value of `bar'.
>>
>> So what's the rule here? global_bar must be written before we run
>> get_online_cpus_stable_atomic()?
>>
>> Anyway, please have a think and spell all this out?
>
> That's right, actually this related to one question, should the hotplug
> happen during get_online and put_online?
>
> Answer will be YES according to old API which using mutex, the hotplug
> won't happen in critical section, but the cost is get_online() will
> block, which will kill the performance.
>
> So we designed this mechanism to do acceleration, but as you pointed
> out, although the result will never be wrong, but the 'stable' mask is
> not stable since it could be changed in critical section.
>
> And we have two solution.
>
> One is from Srivatsa, using 'read_lock' and 'write_lock', it will
> prevent hotplug happen just like the old rule, the cost is we need a
> global 'rw_lock' which perform bad on NUMA system, and no doubt,
> get_online() will block for short time when doing hotplug.
>
> Another is to maintain a per-cpu cache mask, this mask will only be
> updated in get_online(), and be used in critical section, then we will
> get a real stable mask, but one flaw is, on different cpu in critical
> section, online mask will be different.
>
> We will be appreciate if we could collect some comments on which one to
> be used in next version.
>
> Regards,
> Michael Wang
>
>>
>>> struct take_cpu_down_param {
>>> unsigned long mod;
>>> void *hcpu;
>>> @@ -246,7 +351,9 @@ struct take_cpu_down_param {
>>> static int __ref take_cpu_down(void *_param)
>>> {
>>> struct take_cpu_down_param *param = _param;
>>> - int err;
>>> + int err, cpu = (long)(param->hcpu);
>>> +
>>
>> Like this please:
>>
>> int err;
>> int cpu = (long)(param->hcpu);
>>
>>> + prepare_cpu_take_down(cpu);
>>>
>>> /* Ensure this CPU doesn't handle any more interrupts. */
>>> err = __cpu_disable();
>>>
>>> ...
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
next prev parent reply other threads:[~2012-12-05 3:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-04 8:53 [RFC PATCH 00/10] CPU hotplug: stop_machine()-free CPU hotplug Srivatsa S. Bhat
2012-12-04 8:53 ` [RFC PATCH 01/10] CPU hotplug: Introduce "stable" cpu online mask, for atomic hotplug readers Srivatsa S. Bhat
2012-12-04 15:17 ` Tejun Heo
2012-12-04 21:14 ` Srivatsa S. Bhat
2012-12-04 22:10 ` Andrew Morton
2012-12-05 2:56 ` Michael Wang
2012-12-05 3:28 ` Michael Wang [this message]
2012-12-05 12:38 ` Srivatsa S. Bhat
2012-12-04 8:54 ` [RFC PATCH 02/10] smp, cpu hotplug: Fix smp_call_function_*() to prevent CPU offline properly Srivatsa S. Bhat
2012-12-04 22:17 ` Andrew Morton
2012-12-05 12:41 ` Srivatsa S. Bhat
2012-12-04 23:39 ` Rusty Russell
2012-12-04 23:39 ` Rusty Russell
2012-12-05 12:44 ` Srivatsa S. Bhat
2012-12-04 8:54 ` [RFC PATCH 03/10] smp, cpu hotplug: Fix on_each_cpu_*() " Srivatsa S. Bhat
2012-12-04 8:54 ` [RFC PATCH 04/10] sched, cpu hotplug: Use stable online cpus in try_to_wake_up() & select_task_rq() Srivatsa S. Bhat
2012-12-04 8:55 ` [RFC PATCH 05/10] kick_process(), cpu-hotplug: Prevent offlining of target CPU properly Srivatsa S. Bhat
2012-12-04 8:55 ` [RFC PATCH 06/10] yield_to(), cpu-hotplug: Prevent offlining of other CPUs properly Srivatsa S. Bhat
2012-12-04 8:55 ` [RFC PATCH 07/10] KVM: VMX: fix invalid cpu passed to smp_call_function_single Srivatsa S. Bhat
2012-12-04 8:55 ` [RFC PATCH 08/10] KVM: VMX: fix memory order between loading vmcs and clearing vmcs Srivatsa S. Bhat
2012-12-04 8:56 ` [RFC PATCH 09/10] KVM: VMX: fix unsyc vmcs status when cpu is going down Srivatsa S. Bhat
2012-12-04 8:56 ` [RFC PATCH 10/10] cpu: No more __stop_machine() in _cpu_down() Srivatsa S. Bhat
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=50BEBF72.80906@linux.vnet.ibm.com \
--to=wangyun@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=amit.kucheria@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rjw@sisk.pl \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=sbw@mit.edu \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=xiaoguangrong@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.