From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: tglx@linutronix.de, peterz@infradead.org,
paulmck@linux.vnet.ibm.com, rusty@rustcorp.com.au,
mingo@kernel.org, akpm@linux-foundation.org, namhyung@kernel.org,
vincent.guittot@linaro.org, oleg@redhat.com, sbw@mit.edu,
amit.kucheria@linaro.org, rostedt@goodmis.org, rjw@sisk.pl,
wangyun@linux.vnet.ibm.com, xiaoguangrong@linux.vnet.ibm.com,
nikunj@linux.vnet.ibm.com, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
Date: Sat, 08 Dec 2012 00:08:01 +0530 [thread overview]
Message-ID: <50C23789.9000705@linux.vnet.ibm.com> (raw)
In-Reply-To: <20121207183141.GC2821@htj.dyndns.org>
On 12/08/2012 12:01 AM, Tejun Heo wrote:
> Hello, Srivatsa.
>
> On Fri, Dec 07, 2012 at 11:54:01PM +0530, Srivatsa S. Bhat wrote:
>>> lg_lock doesn't do local nesting and I'm not sure how big a deal that
>>> is as I don't know how many should be converted. But if nesting is an
>>> absolute necessity, it would be much better to implement generic
>>> rwlock variant (say, lg_rwlock) rather than implementing unusual
>>> cpuhotplug-specific percpu synchronization construct.
>>
>> To be honest, at a certain point in time while designing this, I did
>> realize that this was getting kinda overly complicated ;-) ... but I
>> wanted to see how this would actually work out when finished and get
>> some feedback on the same, hence I posted it out. But this also proves
>> that we _can_ actually compete with the flexibility of preempt_disable()
>> and still be safe with respect to locking, if we really want to ;-)
>
> I got confused by comparison to preempt_disable() but you're right
> that percpu rwlock shouldn't be able to introduce locking dependency
> which doesn't exist with non-percpu rwlock. ie. write locking should
> be atomic w.r.t. to all readers.
Yep!
> At the simplest, this can be
> implemented by writer backing out all the way if try-locking any CPU
> fails and retrying the whole thing. That should be correct but has
> the potential of starving the writer.
>
Exactly! This is what I mentioned yesterday in the link below, and said
that its not good because of writer starvation ("too wasteful"):
https://lkml.org/lkml/2012/12/6/290
> What we need here is a generic percpu-rwlock. I don't know which
> exact implementation strategy we should choose. Maybe your switching
> to global rwlock is the right solution. But, at any rate, I think it
> would be best to implement proper percpu-rwlock and then apply it to
> CPU hotplug. It's actually gonna be pretty fitting as
> get_online_cpus() is being converted to percpu-rwsem. IIUC, Oleg has
> been working on this for a while now. Oleg, what do you think?
>
Hmm, that sounds good.
Regards,
Srivatsa S. Bhat
next prev parent reply other threads:[~2012-12-07 18:39 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-07 17:37 [RFC PATCH v3 0/9] CPU hotplug: stop_machine()-free CPU hotplug Srivatsa S. Bhat
2012-12-07 17:38 ` [RFC PATCH v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context Srivatsa S. Bhat
2012-12-07 17:57 ` Tejun Heo
2012-12-07 18:16 ` Tejun Heo
2012-12-07 18:33 ` Srivatsa S. Bhat
2012-12-07 18:24 ` Srivatsa S. Bhat
2012-12-07 18:31 ` Tejun Heo
2012-12-07 18:38 ` Srivatsa S. Bhat [this message]
2012-12-09 19:14 ` Oleg Nesterov
2012-12-09 19:50 ` Srivatsa S. Bhat
2012-12-09 20:22 ` Oleg Nesterov
2012-12-10 4:28 ` Srivatsa S. Bhat
2012-12-10 17:24 ` Oleg Nesterov
2012-12-11 13:13 ` Srivatsa S. Bhat
2012-12-11 13:47 ` Tejun Heo
2012-12-11 14:02 ` Srivatsa S. Bhat
2012-12-11 14:07 ` Tejun Heo
2012-12-11 16:28 ` Srivatsa S. Bhat
2012-12-09 21:13 ` Oleg Nesterov
2012-12-10 5:01 ` Srivatsa S. Bhat
2012-12-10 17:28 ` Oleg Nesterov
2012-12-11 13:05 ` Srivatsa S. Bhat
2012-12-09 20:57 ` Oleg Nesterov
2012-12-10 5:19 ` Srivatsa S. Bhat
2012-12-10 18:15 ` Oleg Nesterov
2012-12-11 13:04 ` Srivatsa S. Bhat
2012-12-07 17:38 ` [RFC PATCH v3 2/9] CPU hotplug: Convert preprocessor macros to static inline functions Srivatsa S. Bhat
2012-12-07 17:38 ` [RFC PATCH v3 3/9] smp, cpu hotplug: Fix smp_call_function_*() to prevent CPU offline properly Srivatsa S. Bhat
2012-12-07 17:39 ` [RFC PATCH v3 4/9] smp, cpu hotplug: Fix on_each_cpu_*() " Srivatsa S. Bhat
2012-12-07 17:39 ` [RFC PATCH v3 5/9] sched, cpu hotplug: Use stable online cpus in try_to_wake_up() & select_task_rq() Srivatsa S. Bhat
2012-12-07 17:39 ` [RFC PATCH v3 6/9] kick_process(), cpu-hotplug: Prevent offlining of target CPU properly Srivatsa S. Bhat
2012-12-07 17:39 ` [RFC PATCH v3 7/9] yield_to(), cpu-hotplug: Prevent offlining of other CPUs properly Srivatsa S. Bhat
2012-12-09 19:48 ` Oleg Nesterov
2012-12-09 19:57 ` Srivatsa S. Bhat
2012-12-09 20:40 ` Oleg Nesterov
2012-12-10 4:04 ` Srivatsa S. Bhat
2012-12-07 17:40 ` [RFC PATCH v3 8/9] kvm, vmx: Add atomic synchronization with CPU Hotplug Srivatsa S. Bhat
2012-12-07 17:40 ` [RFC PATCH v3 9/9] 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=50C23789.9000705@linux.vnet.ibm.com \
--to=srivatsa.bhat@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=oleg@redhat.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=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=wangyun@linux.vnet.ibm.com \
--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.