On Thu, 2014-02-13 at 10:56 +, Srivatsa S. Bhat wrote:
> On 02/12/2014 11:48 AM, Srivatsa S. Bhat wrote:
:
> >>> For example, something like the code snippet shown below looks pretty
> >>> neat to me:
> >>>
> >>> cpu_notifier_register_begin();
> >>>
> >>> for_each_online_cpu(cpu)
> >>>
On 02/13/2014 11:14 PM, Oleg Nesterov wrote:
> On 02/12, Srivatsa S. Bhat wrote:
>>
>> On 02/11/2014 10:45 PM, Oleg Nesterov wrote:
>>>
>>> I am a bit confused... If we do this, why we can't simply turn
>>> cpu_add_remove_lock into rw_semaphore?
>
> [...snip...]
>
>>
On 02/12, Srivatsa S. Bhat wrote:
>
> On 02/11/2014 10:45 PM, Oleg Nesterov wrote:
> >
> > I am a bit confused... If we do this, why we can't simply turn
> > cpu_add_remove_lock into rw_semaphore?
[...snip...]
> cpu_notifier_register_begin();| Run in parallel
>
On Mon, Feb 10, 2014 at 06:26:20PM -0700, Toshi Kani wrote:
>
> get/put_online_cpus() is a reader-lock and concurrent executions are
> allowed among the readers. They won't be serialized until a cpu
> online/offline operation begins. By replacing this lock with
> cpu_maps_update_begin/done(),
On 02/12/2014 11:48 AM, Srivatsa S. Bhat wrote:
> On 02/12/2014 02:21 AM, Toshi Kani wrote:
>> On Wed, 2014-02-12 at 00:50 +0530, Srivatsa S. Bhat wrote:
>>> On 02/11/2014 11:05 PM, Toshi Kani wrote:
>> :
How about this? foo_cpu_notifier returns NOP when foo_notifier_ready is
false.
On 02/12/2014 11:48 AM, Srivatsa S. Bhat wrote:
On 02/12/2014 02:21 AM, Toshi Kani wrote:
On Wed, 2014-02-12 at 00:50 +0530, Srivatsa S. Bhat wrote:
On 02/11/2014 11:05 PM, Toshi Kani wrote:
:
How about this? foo_cpu_notifier returns NOP when foo_notifier_ready is
false.
On Mon, Feb 10, 2014 at 06:26:20PM -0700, Toshi Kani wrote:
get/put_online_cpus() is a reader-lock and concurrent executions are
allowed among the readers. They won't be serialized until a cpu
online/offline operation begins. By replacing this lock with
cpu_maps_update_begin/done(), we now
On 02/12, Srivatsa S. Bhat wrote:
On 02/11/2014 10:45 PM, Oleg Nesterov wrote:
I am a bit confused... If we do this, why we can't simply turn
cpu_add_remove_lock into rw_semaphore?
[...snip...]
cpu_notifier_register_begin();| Run in parallel
On 02/13/2014 11:14 PM, Oleg Nesterov wrote:
On 02/12, Srivatsa S. Bhat wrote:
On 02/11/2014 10:45 PM, Oleg Nesterov wrote:
I am a bit confused... If we do this, why we can't simply turn
cpu_add_remove_lock into rw_semaphore?
[...snip...]
cpu_notifier_register_begin();
On Thu, 2014-02-13 at 10:56 +, Srivatsa S. Bhat wrote:
On 02/12/2014 11:48 AM, Srivatsa S. Bhat wrote:
:
For example, something like the code snippet shown below looks pretty
neat to me:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
On 02/12/2014 02:21 AM, Toshi Kani wrote:
> On Wed, 2014-02-12 at 00:50 +0530, Srivatsa S. Bhat wrote:
>> On 02/11/2014 11:05 PM, Toshi Kani wrote:
> :
>>> How about this? foo_cpu_notifier returns NOP when foo_notifier_ready is
>>> false.
>>>
>>> register_cpu_notifier(_cpu_notifier);
>>>
On Wed, 2014-02-12 at 00:50 +0530, Srivatsa S. Bhat wrote:
> On 02/11/2014 11:05 PM, Toshi Kani wrote:
:
> > How about this? foo_cpu_notifier returns NOP when foo_notifier_ready is
> > false.
> >
> > register_cpu_notifier(_cpu_notifier);
> >
> > get_online_cpus();
> >
> >
On 02/11/2014 11:05 PM, Toshi Kani wrote:
> On Tue, 2014-02-11 at 22:48 +0530, Gautham R Shenoy wrote:
>> On Tue, Feb 11, 2014 at 09:33:56AM -0700, Toshi Kani wrote:
>>>
>>> I agree that introducing a reader-writer semaphore allows concurrent
>>> executions. Adding yet another hotplug lock is a
On 02/11/2014 10:45 PM, Oleg Nesterov wrote:
> On 02/11, Srivatsa S. Bhat wrote:
>>
>> +static DECLARE_RWSEM(cpu_hotplug_rwsem);
>> +
>> +void cpu_notifier_register_begin(void)
>> +{
>> +down_read(_hotplug_rwsem);
>> +}
>> +
>> +void cpu_notifier_register_end(void)
>> +{
>> +
On Tue, 2014-02-11 at 22:48 +0530, Gautham R Shenoy wrote:
> On Tue, Feb 11, 2014 at 09:33:56AM -0700, Toshi Kani wrote:
> >
> > I agree that introducing a reader-writer semaphore allows concurrent
> > executions. Adding yet another hotplug lock is a bit unfortunate,
> > though.
> >
>
> I
On Tue, Feb 11, 2014 at 09:33:56AM -0700, Toshi Kani wrote:
>
> I agree that introducing a reader-writer semaphore allows concurrent
> executions. Adding yet another hotplug lock is a bit unfortunate,
> though.
>
I agree with this last part. We already have enough locks for
cpu-hotplug.
On 02/11, Srivatsa S. Bhat wrote:
>
> +static DECLARE_RWSEM(cpu_hotplug_rwsem);
> +
> +void cpu_notifier_register_begin(void)
> +{
> + down_read(_hotplug_rwsem);
> +}
> +
> +void cpu_notifier_register_end(void)
> +{
> + up_read(_hotplug_rwsem);
> +}
> +
> /* Serializes the updates to
On Tue, 2014-02-11 at 09:27 +, Srivatsa S. Bhat wrote:
> On 02/11/2014 06:56 AM, Toshi Kani wrote:
> > On Thu, 2014-02-06 at 03:34 +0530, Srivatsa S. Bhat wrote:
> > :
> [...]
> >>
> >> Also, since cpu_maps_update_begin/done() is like a super-set of
> >> get/put_online_cpus(), the former
On 02/11/2014 06:56 AM, Toshi Kani wrote:
> On Thu, 2014-02-06 at 03:34 +0530, Srivatsa S. Bhat wrote:
> :
[...]
>>
>> Also, since cpu_maps_update_begin/done() is like a super-set of
>> get/put_online_cpus(), the former naturally protects the critical sections
>> from concurrent hotplug
On 02/11/2014 06:56 AM, Toshi Kani wrote:
On Thu, 2014-02-06 at 03:34 +0530, Srivatsa S. Bhat wrote:
:
[...]
Also, since cpu_maps_update_begin/done() is like a super-set of
get/put_online_cpus(), the former naturally protects the critical sections
from concurrent hotplug operations.
On Tue, 2014-02-11 at 09:27 +, Srivatsa S. Bhat wrote:
On 02/11/2014 06:56 AM, Toshi Kani wrote:
On Thu, 2014-02-06 at 03:34 +0530, Srivatsa S. Bhat wrote:
:
[...]
Also, since cpu_maps_update_begin/done() is like a super-set of
get/put_online_cpus(), the former naturally protects
On 02/11, Srivatsa S. Bhat wrote:
+static DECLARE_RWSEM(cpu_hotplug_rwsem);
+
+void cpu_notifier_register_begin(void)
+{
+ down_read(cpu_hotplug_rwsem);
+}
+
+void cpu_notifier_register_end(void)
+{
+ up_read(cpu_hotplug_rwsem);
+}
+
/* Serializes the updates to
On Tue, Feb 11, 2014 at 09:33:56AM -0700, Toshi Kani wrote:
I agree that introducing a reader-writer semaphore allows concurrent
executions. Adding yet another hotplug lock is a bit unfortunate,
though.
I agree with this last part. We already have enough locks for
cpu-hotplug. Another one
On Tue, 2014-02-11 at 22:48 +0530, Gautham R Shenoy wrote:
On Tue, Feb 11, 2014 at 09:33:56AM -0700, Toshi Kani wrote:
I agree that introducing a reader-writer semaphore allows concurrent
executions. Adding yet another hotplug lock is a bit unfortunate,
though.
I agree with this
On 02/11/2014 10:45 PM, Oleg Nesterov wrote:
On 02/11, Srivatsa S. Bhat wrote:
+static DECLARE_RWSEM(cpu_hotplug_rwsem);
+
+void cpu_notifier_register_begin(void)
+{
+down_read(cpu_hotplug_rwsem);
+}
+
+void cpu_notifier_register_end(void)
+{
+up_read(cpu_hotplug_rwsem);
+}
+
On 02/11/2014 11:05 PM, Toshi Kani wrote:
On Tue, 2014-02-11 at 22:48 +0530, Gautham R Shenoy wrote:
On Tue, Feb 11, 2014 at 09:33:56AM -0700, Toshi Kani wrote:
I agree that introducing a reader-writer semaphore allows concurrent
executions. Adding yet another hotplug lock is a bit
On Wed, 2014-02-12 at 00:50 +0530, Srivatsa S. Bhat wrote:
On 02/11/2014 11:05 PM, Toshi Kani wrote:
:
How about this? foo_cpu_notifier returns NOP when foo_notifier_ready is
false.
register_cpu_notifier(foobar_cpu_notifier);
get_online_cpus();
On 02/12/2014 02:21 AM, Toshi Kani wrote:
On Wed, 2014-02-12 at 00:50 +0530, Srivatsa S. Bhat wrote:
On 02/11/2014 11:05 PM, Toshi Kani wrote:
:
How about this? foo_cpu_notifier returns NOP when foo_notifier_ready is
false.
register_cpu_notifier(foobar_cpu_notifier);
On Thu, 2014-02-06 at 03:34 +0530, Srivatsa S. Bhat wrote:
:
> The problem here is that callback registration takes the locks in one order
> whereas the CPU hotplug operations take the same locks in the opposite order.
> To avoid this issue and to provide a race-free method to register CPU
On Mon, Feb 10, 2014 at 04:21:30PM +0530, Gautham R Shenoy wrote:
> On Mon, Feb 10, 2014 at 02:45:55PM +0530, Srivatsa S. Bhat wrote:
>
> + cpuhp_lock_acquire_read();
> mutex_lock(_hotplug.lock);
Don't you want to abstract cpuhp_lock_acquire_read and mutex_lock into a
more useful
On 02/10, Gautham R Shenoy wrote:
>
> Add lockdep annotations for get/put_online_cpus() and
> cpu_hotplug_begin()/cpu_hotplug_end().
Thanks, looks good.
Reviewed-by: Oleg Nesterov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 02/10/2014 04:21 PM, Gautham R Shenoy wrote:
> On Mon, Feb 10, 2014 at 02:45:55PM +0530, Srivatsa S. Bhat wrote:
>> Hi Gautham,
>>
>> On 02/08/2014 12:41 AM, Gautham R Shenoy wrote:
>>> On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
On 02/06, Srivatsa S. Bhat wrote:
>
On 02/10/2014 05:35 PM, Gautham R Shenoy wrote:
> On Mon, Feb 10, 2014 at 04:41:04PM +0530, Srivatsa S. Bhat wrote:
>>> ---
>> [...]
>>> +/* Lockdep annotations for get/put_online_cpus() and
>>> cpu_hotplug_begin/end() */
>>> +#define cpuhp_lock_acquire_read()
>>>
On Mon, Feb 10, 2014 at 04:41:04PM +0530, Srivatsa S. Bhat wrote:
> > ---
> [...]
> > +/* Lockdep annotations for get/put_online_cpus() and
> > cpu_hotplug_begin/end() */
> > +#define cpuhp_lock_acquire_read()
> > lock_map_acquire_read(_hotplug.dep_map)
> > +#define cpuhp_lock_acquire()
On 02/10/2014 04:21 PM, Gautham R Shenoy wrote:
> On Mon, Feb 10, 2014 at 02:45:55PM +0530, Srivatsa S. Bhat wrote:
>> Hi Gautham,
>>
>> On 02/08/2014 12:41 AM, Gautham R Shenoy wrote:
>>> On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
On 02/06, Srivatsa S. Bhat wrote:
>
On Mon, Feb 10, 2014 at 02:45:55PM +0530, Srivatsa S. Bhat wrote:
> Hi Gautham,
>
> On 02/08/2014 12:41 AM, Gautham R Shenoy wrote:
> > On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
> >> On 02/06, Srivatsa S. Bhat wrote:
> >>>
> >>> The following method of CPU hotplug callback
Hi Gautham,
On 02/08/2014 12:41 AM, Gautham R Shenoy wrote:
> On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
>> On 02/06, Srivatsa S. Bhat wrote:
>>>
>>> The following method of CPU hotplug callback registration is not safe
>>> due to the possibility of an ABBA deadlock involving
Hi Gautham,
On 02/08/2014 12:41 AM, Gautham R Shenoy wrote:
On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
On 02/06, Srivatsa S. Bhat wrote:
The following method of CPU hotplug callback registration is not safe
due to the possibility of an ABBA deadlock involving the
On Mon, Feb 10, 2014 at 02:45:55PM +0530, Srivatsa S. Bhat wrote:
Hi Gautham,
On 02/08/2014 12:41 AM, Gautham R Shenoy wrote:
On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
On 02/06, Srivatsa S. Bhat wrote:
The following method of CPU hotplug callback registration is
On 02/10/2014 04:21 PM, Gautham R Shenoy wrote:
On Mon, Feb 10, 2014 at 02:45:55PM +0530, Srivatsa S. Bhat wrote:
Hi Gautham,
On 02/08/2014 12:41 AM, Gautham R Shenoy wrote:
On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
On 02/06, Srivatsa S. Bhat wrote:
The following
On Mon, Feb 10, 2014 at 04:41:04PM +0530, Srivatsa S. Bhat wrote:
---
[...]
+/* Lockdep annotations for get/put_online_cpus() and
cpu_hotplug_begin/end() */
+#define cpuhp_lock_acquire_read()
lock_map_acquire_read(cpu_hotplug.dep_map)
+#define cpuhp_lock_acquire()
On 02/10/2014 05:35 PM, Gautham R Shenoy wrote:
On Mon, Feb 10, 2014 at 04:41:04PM +0530, Srivatsa S. Bhat wrote:
---
[...]
+/* Lockdep annotations for get/put_online_cpus() and
cpu_hotplug_begin/end() */
+#define cpuhp_lock_acquire_read()
lock_map_acquire_read(cpu_hotplug.dep_map)
On 02/10/2014 04:21 PM, Gautham R Shenoy wrote:
On Mon, Feb 10, 2014 at 02:45:55PM +0530, Srivatsa S. Bhat wrote:
Hi Gautham,
On 02/08/2014 12:41 AM, Gautham R Shenoy wrote:
On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
On 02/06, Srivatsa S. Bhat wrote:
The following
On 02/10, Gautham R Shenoy wrote:
Add lockdep annotations for get/put_online_cpus() and
cpu_hotplug_begin()/cpu_hotplug_end().
Thanks, looks good.
Reviewed-by: Oleg Nesterov o...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Mon, Feb 10, 2014 at 04:21:30PM +0530, Gautham R Shenoy wrote:
On Mon, Feb 10, 2014 at 02:45:55PM +0530, Srivatsa S. Bhat wrote:
+ cpuhp_lock_acquire_read();
mutex_lock(cpu_hotplug.lock);
Don't you want to abstract cpuhp_lock_acquire_read and mutex_lock into a
more useful
On Thu, 2014-02-06 at 03:34 +0530, Srivatsa S. Bhat wrote:
:
The problem here is that callback registration takes the locks in one order
whereas the CPU hotplug operations take the same locks in the opposite order.
To avoid this issue and to provide a race-free method to register CPU hotplug
On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
> On 02/06, Srivatsa S. Bhat wrote:
> >
> > The following method of CPU hotplug callback registration is not safe
> > due to the possibility of an ABBA deadlock involving the cpu_add_remove_lock
> > and the cpu_hotplug.lock.
>
>
On Thu, Feb 06, 2014 at 07:41:03PM +0100, Oleg Nesterov wrote:
On 02/06, Srivatsa S. Bhat wrote:
The following method of CPU hotplug callback registration is not safe
due to the possibility of an ABBA deadlock involving the cpu_add_remove_lock
and the cpu_hotplug.lock.
Off-topic, but
On 02/06, Srivatsa S. Bhat wrote:
>
> The following method of CPU hotplug callback registration is not safe
> due to the possibility of an ABBA deadlock involving the cpu_add_remove_lock
> and the cpu_hotplug.lock.
Off-topic, but perhaps it also makes sense to add the lockdep annotations
later,
On 02/06, Srivatsa S. Bhat wrote:
The following method of CPU hotplug callback registration is not safe
due to the possibility of an ABBA deadlock involving the cpu_add_remove_lock
and the cpu_hotplug.lock.
Off-topic, but perhaps it also makes sense to add the lockdep annotations
later, to
The following method of CPU hotplug callback registration is not safe
due to the possibility of an ABBA deadlock involving the cpu_add_remove_lock
and the cpu_hotplug.lock.
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
The following method of CPU hotplug callback registration is not safe
due to the possibility of an ABBA deadlock involving the cpu_add_remove_lock
and the cpu_hotplug.lock.
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
52 matches
Mail list logo
