sabled. So
obviously this whole thing can run in atomic context.
And cmci_rediscover() is called from CPU_POST_DEAD handler. So the CPU
which was supposed to go offline would have already gone offline and
out of the cpu_online_mask. So there is no point checking
'if (cpu == dying)' in th
On 02/07/2013 09:44 AM, Rusty Russell wrote:
> "Srivatsa S. Bhat" writes:
>> On 01/22/2013 01:03 PM, Srivatsa S. Bhat wrote:
>> Avg. latency of 1 CPU offline (ms) [stop-cpu/stop-m/c
>> latency]
>>
>> # online CPUsMainline (with
Memory Power Management:
http://lwn.net/Articles/445045/ (Original posting by Ankita Garg)
http://lwn.net/Articles/523311/ (Forward-port to 3.7-rc3)
3. "Sorted-buddy" design for Memory Power Management:
http://article.gmane.org/gmane.linux.power-management.general/28498/
Rega
On 02/08/2013 09:11 PM, Russell King - ARM Linux wrote:
> On Thu, Feb 07, 2013 at 11:41:34AM +0530, Srivatsa S. Bhat wrote:
>> On 02/07/2013 09:44 AM, Rusty Russell wrote:
>>> "Srivatsa S. Bhat" writes:
>>>> On 01/22/2013 01:03 PM, Srivatsa S. Bhat wrote:
On 02/08/2013 10:14 PM, Srivatsa S. Bhat wrote:
> On 02/08/2013 09:11 PM, Russell King - ARM Linux wrote:
>> On Thu, Feb 07, 2013 at 11:41:34AM +0530, Srivatsa S. Bhat wrote:
>>> On 02/07/2013 09:44 AM, Rusty Russell wrote:
>>>> "Srivatsa S. Bhat" writes:
On 02/09/2013 04:17 AM, Paul E. McKenney wrote:
> On Tue, Jan 29, 2013 at 08:12:37PM +0900, Namhyung Kim wrote:
>> On Thu, 24 Jan 2013 10:00:04 +0530, Srivatsa S. Bhat wrote:
>>> On 01/24/2013 01:27 AM, Tejun Heo wrote:
>>>> On Thu, Jan 24, 2013 at 01:03:52AM
On 02/09/2013 04:40 AM, Paul E. McKenney wrote:
> On Tue, Jan 22, 2013 at 01:03:53PM +0530, Srivatsa S. Bhat wrote:
>> Using global rwlocks as the backend for per-CPU rwlocks helps us avoid many
>> lock-ordering related problems (unlike per-cpu locks). However, global
>
On 02/10/2013 11:36 PM, Oleg Nesterov wrote:
> On 02/08, Paul E. McKenney wrote:
>>
>> On Tue, Jan 22, 2013 at 01:03:53PM +0530, Srivatsa S. Bhat wrote:
>>>
>>> void percpu_read_unlock(struct percpu_rwlock *pcpu_rwlock)
>>> {
>>> - read_un
On 02/09/2013 05:14 AM, Paul E. McKenney wrote:
> On Tue, Jan 22, 2013 at 01:04:11PM +0530, Srivatsa S. Bhat wrote:
>> If interrupt handlers can also be readers, then one of the ways to make
>> per-CPU rwlocks safe, is to disable interrupts at the reader side before
>> tryi
On 02/11/2013 12:12 AM, Oleg Nesterov wrote:
> only one cosmetic nit...
>
> On 01/22, Srivatsa S. Bhat wrote:
>>
>> +#define READER_PRESENT (1UL << 16)
>> +#define READER_REFCNT_MASK (READER_PRESENT - 1)
>> +
>> #defi
On 02/09/2013 05:17 AM, Paul E. McKenney wrote:
> On Tue, Jan 22, 2013 at 01:04:23PM +0530, Srivatsa S. Bhat wrote:
>> CPU hotplug (which will be the first user of per-CPU rwlocks) has a special
>> requirement with respect to locking: the writer, after acquiring the per-CPU
>
Hi Namhyung,
On 01/29/2013 03:51 PM, Namhyung Kim wrote:
> Hi Srivatsa,
>
> On Tue, 22 Jan 2013 13:04:54 +0530, Srivatsa S. Bhat wrote:
>> @@ -246,15 +291,21 @@ struct take_cpu_down_param {
>> static int __ref take_cpu_down(void *_param)
>> {
>> struct ta
On 02/09/2013 05:37 AM, Paul E. McKenney wrote:
> On Tue, Jan 22, 2013 at 01:05:10PM +0530, Srivatsa S. Bhat wrote:
>> Once stop_machine() is gone from the CPU offline path, we won't be able to
>> depend on preempt_disable() to prevent CPUs from going offline from under u
On 02/09/2013 05:44 AM, Paul E. McKenney wrote:
> On Tue, Jan 22, 2013 at 01:06:34PM +0530, Srivatsa S. Bhat wrote:
>> Don't refer to stop_machine() in the CPU hotplug path, since we are going
>> to get rid of it. Also, move the comment referring to callback adoption
>
On 02/09/2013 05:45 AM, Paul E. McKenney wrote:
> On Tue, Jan 22, 2013 at 01:15:22PM +0530, Srivatsa S. Bhat wrote:
>> ... and also cleanup a comment that refers to CPU hotplug being dependent on
>> stop_machine().
>>
>> Cc: David Howells
>> Signed-off-by: Srivats
On 02/11/2013 01:17 AM, Paul E. McKenney wrote:
> On Mon, Feb 11, 2013 at 12:40:56AM +0530, Srivatsa S. Bhat wrote:
>> On 02/09/2013 04:40 AM, Paul E. McKenney wrote:
>>> On Tue, Jan 22, 2013 at 01:03:53PM +0530, Srivatsa S. Bhat wrote:
>>>> Using global rwlocks as t
On 02/11/2013 01:26 AM, Paul E. McKenney wrote:
> On Mon, Feb 11, 2013 at 01:11:29AM +0530, Srivatsa S. Bhat wrote:
>> On 02/09/2013 05:37 AM, Paul E. McKenney wrote:
>>> On Tue, Jan 22, 2013 at 01:05:10PM +0530, Srivatsa S. Bhat wrote:
>>>> Once stop_machine() is
On 02/11/2013 01:20 AM, Oleg Nesterov wrote:
> On 02/11, Srivatsa S. Bhat wrote:
>>
>> On 02/10/2013 11:36 PM, Oleg Nesterov wrote:
>>>>> +static void announce_writer_inactive(struct percpu_rwlock *pcpu_rwlock)
>>>>> +{
>>>>> + unsign
On 02/11/2013 01:43 AM, Oleg Nesterov wrote:
> On 02/11, Srivatsa S. Bhat wrote:
>>
>> On 02/09/2013 04:40 AM, Paul E. McKenney wrote:
>>>> +static void announce_writer_inactive(struct percpu_rwlock *pcpu_rwlock)
>>>> +{
>>>> + unsigned int
On 02/11/2013 05:28 PM, Vincent Guittot wrote:
> On 8 February 2013 19:09, Srivatsa S. Bhat
> wrote:
>> On 02/08/2013 10:14 PM, Srivatsa S. Bhat wrote:
>>> On 02/08/2013 09:11 PM, Russell King - ARM Linux wrote:
>>>> On Thu, Feb 07, 2013 at 11:41:34AM +0530, Sriva
On 02/11/2013 06:11 PM, David Howells wrote:
> Srivatsa S. Bhat wrote:
>
>> We can use global rwlocks as shown below safely, without fear of deadlocks:
>>
>> Readers:
>>
>> CPU 0CPU 1
>> --
On 02/12/2013 12:38 AM, Paul E. McKenney wrote:
> On Mon, Feb 11, 2013 at 05:53:41PM +0530, Srivatsa S. Bhat wrote:
>> On 02/11/2013 05:28 PM, Vincent Guittot wrote:
>>> On 8 February 2013 19:09, Srivatsa S. Bhat
>>> wrote:
>
> [ . . . ]
>
>>>> Ad
On 03/20/2013 03:31 PM, Srivatsa S. Bhat wrote:
[...]
> >
>
> From: Srivatsa S. Bhat
> Subject: [PATCH] x86/mce: Rework cmci_rediscover() to play well with CPU
> hotplug
>
> Dave Jones reports that offlining a
f263. Any ideas?
>
Dave Jones had reported a similar problem some time back and Hillf had
proposed a fix. I guess it slipped through the cracks and never went
upstream.
Here is the link: https://lkml.org/lkml/2013/1/19/1
Can you please try it and see if it improves anything?
Reg
robably would be best to route
> these patches together, so probably not a very good idea to apply this
> to blackfin right now.
>
Thanks Tejun for pointing that out! I'll address the review comments
soon and respin the patchset.
Regards,
Srivatsa S. Bhat
--
To unsubscribe from
unts, and
we consciously avoid waiting/spinning on them (because then that would be
equivalent to having per-cpu locks, which are deadlock-prone). We use
global rwlocks to get the deadlock-safety that we need.
> + write_lock(&lgrw->fallback_rwlock);
> +}
> +EXPORT_SYMBOL(lg_rwlock_global_write_lock);
> +
> +void lg_rwlock_global_write_unlock(struct lgrwlock *lgrw)
> +{
> + write_unlock(&lgrw->fallback_rwlock);
> + lg_global_unlock(&lgrw->lglock);
> +}
> +EXPORT_SYMBOL(lg_rwlock_global_write_unlock);
>
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 02/22/2013 06:01 AM, Rusty Russell wrote:
> "Srivatsa S. Bhat" writes:
>> Hi,
>>
>> This patchset removes CPU hotplug's dependence on stop_machine() from the CPU
>> offline path and provides an alternative (set of APIs) to preempt_disable()
>>
On 02/26/2013 05:47 AM, Lai Jiangshan wrote:
> On Tue, Feb 26, 2013 at 3:26 AM, Srivatsa S. Bhat
> wrote:
>> Hi Lai,
>>
>> On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
>>> Hi, Srivatsa,
>>>
>>> The target of the whole patchset is nice for
Hi Lai,
I'm really not convinced that piggy-backing on lglocks would help
us in any way. But still, let me try to address some of the points
you raised...
On 02/26/2013 06:29 PM, Lai Jiangshan wrote:
> On Tue, Feb 26, 2013 at 5:02 PM, Srivatsa S. Bhat
> wrote:
>> On 02/26/2
On 02/26/2013 07:47 PM, Lai Jiangshan wrote:
> On Mon, Feb 18, 2013 at 8:38 PM, Srivatsa S. Bhat
> wrote:
>> Using global rwlocks as the backend for per-CPU rwlocks helps us avoid many
>> lock-ordering related problems (unlike per-cpu locks). However, global
>> rwlocks l
On 02/26/2013 07:04 PM, Lai Jiangshan wrote:
> On Tue, Feb 26, 2013 at 3:26 AM, Srivatsa S. Bhat
> wrote:
>> Hi Lai,
>>
>> On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
>>> Hi, Srivatsa,
>>>
>>> The target of the whole patchset is nice for me.
&g
On 02/26/2013 09:55 PM, Lai Jiangshan wrote:
> On Tue, Feb 26, 2013 at 10:22 PM, Srivatsa S. Bhat
> wrote:
>>
>> Hi Lai,
>>
>> I'm really not convinced that piggy-backing on lglocks would help
>> us in any way. But still, let me try to address some of t
On 02/27/2013 06:03 AM, Lai Jiangshan wrote:
> On Wed, Feb 27, 2013 at 3:30 AM, Srivatsa S. Bhat
> wrote:
>> On 02/26/2013 09:55 PM, Lai Jiangshan wrote:
>>> On Tue, Feb 26, 2013 at 10:22 PM, Srivatsa S. Bhat
>>> wrote:
>>>>
>>>> Hi Lai,
&g
On 02/18/2013 11:37 PM, Michel Lespinasse wrote:
> On Tue, Feb 19, 2013 at 1:56 AM, Srivatsa S. Bhat
> wrote:
>> On 02/18/2013 09:51 PM, Srivatsa S. Bhat wrote:
>>> On 02/18/2013 09:15 PM, Michel Lespinasse wrote:
>>>> I don't see anything preventing
On 02/18/2013 10:51 PM, Michel Lespinasse wrote:
> On Tue, Feb 19, 2013 at 12:43 AM, Srivatsa S. Bhat
> wrote:
>> On 02/18/2013 09:53 PM, Michel Lespinasse wrote:
>>> I am wondering though, if you could take care of recursive uses in
>>> get/put_online_cpus_ato
On 02/19/2013 03:10 PM, Michel Lespinasse wrote:
> On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat
> wrote:
>> But, the whole intention behind removing the parts depending on the
>> recursive property of rwlocks would be to make it easier to make rwlocks
>> fair (go
r one you mentioned. They probably need to use per-cpu
rw-semaphore or some such, which allows sleeping. I'm not very certain
of the exact usecases you are talking about, but I just wanted to
point out that percpu-rwlocks might not be applicable to many scenarios.
..(which might be a good
On 02/19/2013 11:40 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 22, 2013 at 01:10:51PM +0530, Srivatsa S. Bhat wrote:
>> Once stop_machine() is gone from the CPU offline path, we won't be able to
>> depend on preempt_disable() or local_irq_disable() to prevent CPUs from
&
On 09/10/2012 06:46 PM, Neil Horman wrote:
> On Mon, Sep 10, 2012 at 02:59:18PM +0530, Srivatsa S. Bhat wrote:
>> On 07/23/2012 05:10 PM, Neil Horman wrote:
>>> On Mon, Jul 23, 2012 at 09:15:05AM +0800, Gao feng wrote:
>>>> 于 2012年07月20日 00:27, Srivatsa S. Bhat 写道:
&g
The update_netdev_tables() function appears to be unnecessary, since the
write_update_netdev_table() function will adjust the priomaps as and when
required anyway. So drop the usage of update_netdev_tables() entirely.
Signed-off-by: Srivatsa S. Bhat
---
net/core/netprio_cgroup.c | 32
* Check for non-NULL old_priomap outside the loop, since its
not going to change.
* Copy the old_priomap's length to a local variable and use
that for loop control, instead of costly pointer-dereferences.
Signed-off-by: Srivatsa S. Bhat
---
net/core/netprio_cgroup.c | 12 +++---
p,
> old_priomap->priomap_len * sizeof old_priomap->priomap[0]);
>
Ah, indeed that would be better. I'll send out an updated version of the
patches. Thanks!
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
The update_netdev_tables() function appears to be unnecessary, since the
write_update_netdev_table() function will adjust the priomaps as and when
required anyway. So drop the usage of update_netdev_tables() entirely.
Signed-off-by: Srivatsa S. Bhat
---
net/core/netprio_cgroup.c | 32
Replace the current (inefficient) for-loop with memcpy, to copy priomap.
Signed-off-by: Srivatsa S. Bhat
---
net/core/netprio_cgroup.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index fd339bb0..83bbd0e
On 09/12/2012 01:19 PM, David Miller wrote:
> From: "Srivatsa S. Bhat"
> Date: Wed, 12 Sep 2012 11:37:47 +0530
>
>> +memcpy(new_priomap->priomap, old_priomap->priomap,
>> +old_priomap->priomap_len *
>> +
On 09/12/2012 01:54 PM, Srivatsa S. Bhat wrote:
> On 09/12/2012 01:19 PM, David Miller wrote:
>> From: "Srivatsa S. Bhat"
>> Date: Wed, 12 Sep 2012 11:37:47 +0530
>>
>>> + memcpy(new_priomap->priomap, old_priomap->priomap,
&g
On 07/19/2012 10:45 PM, Paul E. McKenney wrote:
> On Thu, Jul 19, 2012 at 05:39:30PM +0530, Srivatsa S. Bhat wrote:
>> Hi Paul,
>>
>> While running a CPU hotplug stress test on v3.5-rc7+
>> (mainline commit 8a7298b7805ab) I hit this warning.
>> I haven't
Replace the current (inefficient) for-loop with memcpy, to copy priomap.
Signed-off-by: Srivatsa S. Bhat
---
net/core/netprio_cgroup.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index fd339bb0..45c503e
The update_netdev_tables() function appears to be unnecessary, since the
write_update_netdev_table() function will adjust the priomaps as and when
required anyway. So drop the usage of update_netdev_tables() entirely.
Signed-off-by: Srivatsa S. Bhat
---
net/core/netprio_cgroup.c | 32
On 09/12/2012 06:06 PM, Srivatsa S. Bhat wrote:
> On 07/19/2012 10:45 PM, Paul E. McKenney wrote:
>> On Thu, Jul 19, 2012 at 05:39:30PM +0530, Srivatsa S. Bhat wrote:
>>> Hi Paul,
>>>
>>> While running a CPU hotplug stress test on v3.5-rc7+
>>> (main
On 09/13/2012 12:00 PM, Michael Wang wrote:
> On 09/12/2012 11:31 PM, Paul E. McKenney wrote:
>> On Wed, Sep 12, 2012 at 06:06:20PM +0530, Srivatsa S. Bhat wrote:
>>> On 07/19/2012 10:45 PM, Paul E. McKenney wrote:
>>>> On Thu, Jul 19, 2012 at 05:39:30PM +0530, Sr
The CPU_STARTING notifiers are supposed to be run with irqs disabled. But the
perf_cpu_notifier() macro invokes them without doing that. Fix it.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/perf_event.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include
The perf_cpu_notifier() macro invokes smp_processor_id() multiple
times. Optimize it by using a local variable.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/perf_event.h |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/perf_event.h b/include
On 09/14/2012 05:17 PM, Fengguang Wu wrote:
> On Thu, Sep 13, 2012 at 02:05:17PM +0530, Srivatsa S. Bhat wrote:
>> On 09/12/2012 06:06 PM, Srivatsa S. Bhat wrote:
>>> On 07/19/2012 10:45 PM, Paul E. McKenney wrote:
>>>> On Thu, Jul 19, 2012 at 05:39:30PM +0530, Sr
On 09/14/2012 05:55 PM, Peter Zijlstra wrote:
> On Fri, 2012-09-14 at 17:48 +0530, Srivatsa S. Bhat wrote:
>> #! /bin/bash
>
> CPUPATH="/sys/devices/system/cpu"
>
>> NUMBER_OF_CPUS=`ls -d /sys/devices/system/cpu/cpu[0-9]* | wc -l`
>
> apply the above
&g
On 10/02/2012 02:04 PM, Dan Carpenter wrote:
> Using ARRAY_SIZE() is more readable.
>
> Signed-off-by: Dan Carpenter
>
Reviewed-by: Srivatsa S. Bhat
Regards,
Srivatsa S. Bhat
> diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c
> b/arch/x86/kernel/cpu/intel_cacheinfo
ork){+.+.+.}, at: []
> process_one_work+0x1a2/0x4c0
> #2: (net_mutex){+.+.+.}, at: [] cleanup_net+0x80/0x1b0
> #3: (slab_mutex){+.+.+.}, at: []
> kmem_cache_destroy+0x45/0xe0
>
I don't see how this circular locking dependency can occur.. If you are using
SLUB,
kmem_c
On 10/03/2012 03:47 AM, Jiri Kosina wrote:
> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>
>> I don't see how this circular locking dependency can occur.. If you are
>> using SLUB,
>> kmem_cache_destroy() releases slab_mutex before it calls rcu_barrier().
_cpu_up()
> cpu_hotplug_begin()
> mutex_lock(cpu_hotplug.lock)
> rcu_barrier()
> _rcu_barrier()
> get_online_
antly more complex. I cannot say that I am all that happy
> about anyone calling rcu_barrier() from a CPU hotplug notifier because
> it doesn't help CPU hotplug latency, but that is a separate issue.
>
> But the thing is that rcu_barrier()'s assumptions work just fine if
On 10/03/2012 09:14 AM, Paul E. McKenney wrote:
> On Wed, Oct 03, 2012 at 09:05:31AM +0530, Srivatsa S. Bhat wrote:
>> On 10/03/2012 03:47 AM, Jiri Kosina wrote:
>>> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>>>
>>>> I don't see how this circul
On 10/03/2012 09:37 AM, Paul E. McKenney wrote:
> On Wed, Oct 03, 2012 at 09:29:01AM +0530, Srivatsa S. Bhat wrote:
>> On 10/03/2012 05:01 AM, Paul E. McKenney wrote:
>>> On Tue, Oct 02, 2012 at 11:58:36PM +0200, Jiri Kosina wrote:
>>>> On Tue,
On 10/03/2012 09:20 AM, Srivatsa S. Bhat wrote:
> On 10/03/2012 06:15 AM, Jiri Kosina wrote:
>> On Tue, 2 Oct 2012, Paul E. McKenney wrote:
>>
>>> On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
>>>> On Tue, 2 Oct 2012, Paul E. McKenney wrote:
On 10/03/2012 01:13 PM, Jiri Kosina wrote:
> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>
>>>>> CPU 0 CPU 1
>>>>> kmem_cache_destroy()
>>>>
>>>> What about the get_online_cpus() right here at CPU0 be
On 10/03/2012 11:38 AM, Srivatsa S. Bhat wrote:
> On 10/03/2012 09:20 AM, Srivatsa S. Bhat wrote:
>> On 10/03/2012 06:15 AM, Jiri Kosina wrote:
>>> On Tue, 2 Oct 2012, Paul E. McKenney wrote:
>>>
>>>> On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina
On 10/03/2012 01:49 PM, Jiri Kosina wrote:
> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>
>> On 10/03/2012 01:13 PM, Jiri Kosina wrote:
>>> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>>>
>>>>>>> CPU 0
On 10/03/2012 02:54 PM, Jiri Kosina wrote:
> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>
>>>> static void cpu_hotplug_begin(void)
>>>> {
>>>> cpu_hotplug.active_writer = current;
>>>>
>>>> for (;;) {
>>&
quot;
> semantics is totally invisible to lockdep.
>
> This patch therefore moves the unlock of slab_mutex so that rcu_barrier()
> is being called with it unlocked. It has two advantages:
>
> - it slightly reduces hold time of slab_mutex; as it's used to protect
> the ca
On 10/03/2012 05:52 PM, Srivatsa S. Bhat wrote:
> On 10/03/2012 03:16 PM, Jiri Kosina wrote:
>> On Wed, 3 Oct 2012, Jiri Kosina wrote:
>>
>>> Good question. I believe it should be safe to drop slab_mutex earlier, as
>>> cachep has already been unlinked. I am a
On 10/03/2012 08:20 PM, Paul E. McKenney wrote:
> On Wed, Oct 03, 2012 at 05:52:26PM +0530, Srivatsa S. Bhat wrote:
>> On 10/03/2012 03:16 PM, Jiri Kosina wrote:
>>> On Wed, 3 Oct 2012, Jiri Kosina wrote:
>>>
>>>> Good question. I believe it should
rier() dependency on
> __stop_machine()") introduced slab_mutex -> cpu_hotplug.lock
> dependency through kmem_cache_destroy() -> rcu_barrier() ->
> _rcu_barrier() -> get_online_cpus().
>
> Lockdep thinks that this might actually result in ABBA deadlock,
> and reports it as bel
On 10/03/2012 08:35 PM, Jiri Kosina wrote:
> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>
>>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>>> index 9c21725..90c3053 100644
>>> --- a/mm/slab_common.c
>>> +++ b/mm/slab_common.c
>>> @@ -166,6
On 10/04/2012 02:43 AM, Andrew Morton wrote:
> On Wed, 03 Oct 2012 18:23:09 +0530
> "Srivatsa S. Bhat" wrote:
>
>> The synchronization between CPU hotplug readers and writers is achieved by
>> means of refcounting, safe-guarded by the cpu_hotplug.lock.
>>
Hi,
With the mainline kernel (in the merge window) I am seeing the following lockdep
splat every time during boot.
Regards,
Srivatsa S. Bhat
>
[3.940316] SCSI subsystem initialized
[3.949021] Fusion MPT base driver 3.04.20
[3.953141] Copyright
>lock(&(&ha->vport_slock)->rlock);
>
> lock(&(&ha->hardware_lock)->rlock);
> === [ cut here ] ===
>
> Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.
>
> Reported-by: Srivat
On 10/05/2012 08:54 AM, Yasuaki Ishimatsu wrote:
> 2012/10/04 15:16, Srivatsa S. Bhat wrote:
>> On 10/04/2012 02:43 AM, Andrew Morton wrote:
>>> On Wed, 03 Oct 2012 18:23:09 +0530
>>> "Srivatsa S. Bhat" wrote:
>>>
>>>> The synchronizatio
On 09/13/2012 08:12 PM, Srivatsa S. Bhat wrote:
> The CPU_STARTING notifiers are supposed to be run with irqs disabled. But the
> perf_cpu_notifier() macro invokes them without doing that. Fix it.
>
> Signed-off-by: Srivatsa S. Bhat
> ---
Any thoughts on this?
Regards,
S
Hi Nicholas,
On 10/05/2012 12:14 AM, Nicholas A. Bellinger wrote:
> On Thu, 2012-10-04 at 21:11 +0530, Srivatsa S. Bhat wrote:
>> Hi Jiri,
>>
>> Thanks for taking a look!
>
> Hi Srivatsa & Jiri,
>
>>
>>> This seems to be real. You should
t; IRQs enabled?
>
> The patch is no doubt wrong...
>
> The discuss in:
>
> https://lkml.org/lkml/2012/7/19/164
>
> Which also faced the issue that the timer interrupt come in after apic
> was shut down, I'm not sure whether this could do help to Huacai, just
> as a clue.
On 07/26/2012 04:32 PM, Thomas Gleixner wrote:
> On Wed, 25 Jul 2012, Srivatsa S. Bhat wrote:
>> On 07/25/2012 10:00 PM, Thomas Gleixner wrote:
>>> While I thought about having a full dependency tracking system, I'm
>>> quite convinced by now, that hotplug i
On 07/26/2012 04:25 PM, Thomas Gleixner wrote:
> On Wed, 25 Jul 2012, Srivatsa S. Bhat wrote:
>> On 07/25/2012 10:00 PM, Thomas Gleixner wrote:
>>> struct hotplug_event hotplug_events_bp[CPU_HOTPLUG_MAX_EVENTS];
>>> struct hotplug_event hotplug_events_ap[CPU_HOTPLUG_M
On 07/25/2012 10:00 PM, Thomas Gleixner wrote:
> On Wed, 25 Jul 2012, Srivatsa S. Bhat wrote:
>> On 07/25/2012 08:27 PM, Alan Stern wrote:
>> One of the other ideas to improve the hotplug notifier stuff that came up
>> during some
>> of the discussions was to im
have case statements for the
2 cases that imply atomic context and return immediately?
Something like:
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_STARTING:
case CPU_DYING:
return NOTIFY_OK;
}
Regards,
Srivatsa S. Bhat
> mutex_lock(&c
PRI_SCHED_ACTIVE
priority to ensure that the ordering of callbacks is right, isn't it?
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
On 09/24/2012 03:42 PM, Peter Zijlstra wrote:
> On Mon, 2012-09-24 at 15:27 +0530, Srivatsa S. Bhat wrote:
>> On 09/24/2012 03:08 PM, Peter Zijlstra wrote:
>>>> + hotcpu_notifier(sched_domains_numa_masks_update,
>>>> CPU_PRI_SCHED_ACTIVE);
>>>&
alues of num and den), the least value that num or den can have
is zero. So, the C code to guard against divide-by-zero looks OK to me.
Which unfortunately keeps the mystery unsolved :(
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 09/24/2012 04:35 PM, Borislav Petkov wrote:
> On Mon, Sep 24, 2012 at 04:08:33PM +0530, Srivatsa S. Bhat wrote:
>> On 09/24/2012 03:53 PM, Borislav Petkov wrote:
>>> Hi all,
>>>
>>> we're able to trigger the oops below when doing CPU hotplug tests.
>
On 09/24/2012 05:04 PM, Fengguang Wu wrote:
> On Mon, Sep 24, 2012 at 04:43:11PM +0530, Srivatsa S. Bhat wrote:
>> On 09/24/2012 04:35 PM, Borislav Petkov wrote:
>>> On Mon, Sep 24, 2012 at 04:08:33PM +0530, Srivatsa S. Bhat wrote:
>>>> On 09/24/2012 03:53 PM, Boris
U. So, though the synchronization is a bit weird, I don't
immediately see a problematic race condition there.
And, speaking of hotplug callbacks, on a slightly different note,
I see one defined as ratelimit_handler(), which calls
writeback_set_ratelimit() for *every single* state change in
o have in common is that both happen when a CPU
> comes online. Srivatsa's is when CPU9 comes online (oops is detected on
> CPU9) and in our case CPU4 comes online but the oops says CPU0.
>
I had posted another dump from one of my tests. That one triggers while
offlining a CPU (CPU 9
From: Srivatsa S. Bhat
The CPU hotplug callback related to writeback calls writeback_set_ratelimit()
during every state change in the hotplug sequence. This is unnecessary
since num_online_cpus() changes only once during the entire hotplug operation.
So invoke the function only once per
On 09/10/2012 04:43 PM, Srivatsa S. Bhat wrote:
> From: Michal Hocko
>
> Git commit 09a1d34f8535ecf9 "nohz: Make idle/iowait counter update
> conditional" introduced a bug in regard to cpu hotplug. The effect is
> that the number of idle ticks in the cpu summary line
o get rid
> of the problem.
>
> I tried that, but the laptop wouldn't suspend.
>
> Any ideas?
>
(Adding relevant people to CC)
I recall seeing a similar problem getting fixed in mainline quite a long
time ago (around v3.3 I think). Did you try the latest mainline
} else if (cpumask_test_cpu(cpu, data->affinity))
> + cpumask_clear_cpu(cpu, data->affinity);
>
You meant to use 'affinity' (instead of data->affinity) in the above 2
statements
right? Note that we do chip->irq_set_affinity(data, affinity, true);
ata->affinity right?
Btw, on a slightly different note, I'm also rather surprised that the above
code doesn't care about the return value of chip->irq_set_affinity() ..
Shouldn't we warn if that fails?
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line
is NULL and doesn't care if chip->irq_set_affinity was not NULL and
the function failed to set the affinity (ie., when chip->irq_set_affinity()
returns error). In other words, I meant to say that this is one more
case where we need to warn about our failure to set the irq affinity.
Regards,
S
, just CPU0,1,2 will
> receive the interrupts.
>
> But after the CPU3 is online again, we will not set affinity,the result
> will be:
> the smp_affinity is f, but still just CPU0,1,2 can receive the interrupts.
>
> So we should clean the offlining CPU from irq affinity mask
&
Hmm.. no, I wouldn't jump to do that. Moreover, note that there are patches in
-tip to
enable CPU 0 hotplug. So doing the above might not be terribly helpful going
forward.
> I guess this case should be covered outside fixup_irqs() code.
>
Regards,
Srivatsa S. Bhat
--
To unsubscri
On 09/26/2012 02:26 PM, Liu, Chuansheng wrote:
>> A return value of 0 and 1 are acceptable. So this check isn't correct.
>>
>> Regards,
>> Srivatsa S. Bhat
>>
> Which case value 1 is acceptable, could you share? Thanks.
I can see the following in include/lin
On 09/13/2012 06:17 PM, Srivatsa S. Bhat wrote:
> On 09/13/2012 12:00 PM, Michael Wang wrote:
>> On 09/12/2012 11:31 PM, Paul E. McKenney wrote:
>>> On Wed, Sep 12, 2012 at 06:06:20PM +0530, Srivatsa S. Bhat wrote:
>>>> On 07/19/2012 10:45 PM, Paul E. McKenney wrote:
1 - 100 of 1351 matches
Mail list logo
