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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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);
hotcpu_notifier(cpuset_cpu_active
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 in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
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.
I hit this problem as well, which I reported here
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, Borislav Petkov wrote:
Hi all,
we're able
calls
writeback_set_ratelimit() for *every single* state change in the
hotplug sequence! Is that really intentional? num_online_cpus()
changes its value only -once- for every hotplug :-)
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
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).
https://lkml.org/lkml/2012/9/14/235
So it has to be hotplug-related.
Regards,
Srivatsa S
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
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
On 09/10/2012 04:43 PM, Srivatsa S. Bhat wrote:
From: Michal Hocko mho...@suse.cz
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 in /proc/stat
getting fixed in mainline quite a long
time ago (around v3.3 I think). Did you try the latest mainline kernel?
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
) in the above 2
statements
right? Note that we do chip-irq_set_affinity(data, affinity, true); further
down.
Regards,
Srivatsa S. Bhat
chip = irq_data_get_irq_chip(data);
if (!irqd_can_move_in_process_context(data) chip-irq_mask)
--
To unsubscribe from this list: send
if that fails?
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/
-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,
Srivatsa S. Bhat
--
To unsubscribe from this list
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
in fixup_irqs().
Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
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 unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
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/linux/irq.h:
/*
* Return value for chip
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:
On Thu, Jul 19, 2012 at 05:39:30PM
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
in fixup_irqs().
Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
even saw a device interrupt), which I have
reported in another thread at: https://lkml.org/lkml/2012/9/26/119
But this issue in fixup_irqs() that Liu brought to light looks even more
surprising to me..
Regards,
Srivatsa S. Bhat
---
arch/x86/kernel/irq.c | 21 +
1 files
On 09/26/2012 10:36 PM, Suresh Siddha wrote:
On Wed, 2012-09-26 at 21:33 +0530, Srivatsa S. Bhat wrote:
I have some fundamental questions here:
1. Why was the CPU never removed from the affinity masks in the original
code? I find it hard to believe that it was just an oversight, because
On 09/27/2012 04:16 AM, Suresh Siddha wrote:
On Wed, 2012-09-26 at 23:00 +0530, Srivatsa S. Bhat wrote:
On 09/26/2012 10:36 PM, Suresh Siddha wrote:
On Wed, 2012-09-26 at 21:33 +0530, Srivatsa S. Bhat wrote:
I have some fundamental questions here:
1. Why was the CPU never removed from
On 09/27/2012 08:29 AM, Michael Wang wrote:
On 09/26/2012 05:35 PM, Srivatsa S. Bhat wrote:
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
On 09/28/2012 12:50 AM, Suresh Siddha wrote:
On Fri, 2012-09-28 at 00:12 +0530, Srivatsa S. Bhat wrote:
On 09/27/2012 04:16 AM, Suresh Siddha wrote:
No. irq_set_affinity()
Um? That takes the updated/changed affinity and sets data-affinity to
that value no? You mentioned that probably
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:
Indeed. Slab seems to be doing an rcu_barrier
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 before
calling mutex_lock(slab_mutex)? How can the cpu_up() proceed
on CPU1?? I still
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 wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote
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 CPU 1
kmem_cache_destroy()
What about the get_online_cpus() right
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 (;;) {
mutex_lock(cpu_hotplug.lock);
if (likely(!cpu_hotplug.refcount
warning, as it avoids lockdep ever
learning about slab_mutex - cpu_hotplug.lock dependency
Reviewed-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Earlier I was under the wrong impression
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 adding slab people and linux-mm to
CC
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 be safe to drop slab_mutex earlier, as
cachep has already
() - rcu_barrier() -
_rcu_barrier() - get_online_cpus().
Lockdep thinks that this might actually result in ABBA deadlock,
and reports it as below:
[...]
Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Reviewed-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Acked-by: Christoph Lameter c
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 +166,7 @@ void kmem_cache_destroy(struct kmem_cache *s)
s
On 10/04/2012 02:43 AM, Andrew Morton wrote:
On Wed, 03 Oct 2012 18:23:09 +0530
Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote:
The synchronization between CPU hotplug readers and writers is achieved by
means of refcounting, safe-guarded by the cpu_hotplug.lock.
get_online_cpus
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 (c
IRQs while holding ha-vport_slock.
Reported-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
Tested-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Regards,
Srivatsa S. Bhat
---
drivers/scsi/qla2xxx/qla_init.c |5 +++--
1 files
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 srivatsa.b...@linux.vnet.ibm.com wrote:
The synchronization between CPU hotplug readers and writers
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 srivatsa.b...@linux.vnet.ibm.com
---
Any thoughts
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 be seeing that since 3.5-rc1 already
though ... ?
Does the patch
for me. Thanks.
Could you share the patch please? Looks like it didn't hit the mailing
lists..
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
On 10/07/2012 10:41 PM, Kirill A. Shutemov wrote:
On Sun, Oct 07, 2012 at 10:35:01PM +0530, Srivatsa S. Bhat wrote:
On 10/07/2012 10:20 PM, Kirill A. Shutemov wrote:
On Sun, Oct 07, 2012 at 09:03:11AM -0700, Paul E. McKenney wrote:
On Sun, Oct 07, 2012 at 05:47:11AM +0300, Kirill A. Shutemov
-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
This needs a CC to stable also right?
Regards,
Srivatsa S. Bhat
---
drivers/scsi/qla2xxx/qla_init.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi
-flags.power evaluates to zero, hence dev is never
allocated. This causes the NULL pointer (dev) dereference in
cpuidle_disable_device() during a subsequent CPU online operation. Fix this
by ensuring that dev is non-NULL before dereferencing.
Signed-off-by: Srivatsa S. Bhat srivatsa.b
+++-
mm/vmscan.c| 364 +++-
mm/vmstat.c| 71 +
8 files changed, 631 insertions(+), 394 deletions(-)
Thanks,
Srivatsa S. Bhat
IBM Linux Technology Center
--
To unsubscribe from this list: send
allocated at this point.
ToDo:
However, since the number of regions actually present on the system might be
much
smaller than the maximum allowed, dynamic bootmem allocation could be used to
save
memory.
Signed-off-by: Ankita Garg gargank...@gmail.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b
From: Ankita Garg gargank...@gmail.com
With the introduction of regions, helper routines are needed to walk through
all the regions and zones inside a node. This patch adds these helper
routines.
Signed-off-by: Ankita Garg gargank...@gmail.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b
related steps continue to be unmodified.
Signed-off-by: Ankita Garg gargank...@gmail.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/mm.h |2 +
mm/page_alloc.c| 175 ++--
2 files changed, 118 insertions
-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/mm.h |2 -
include/linux/mmzone.h |9 ++-
mm/page_alloc.c| 128 +++-
3 files changed, 79 insertions(+), 60 deletions(-)
diff --git a/include/linux/mm.h b
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
mm/page_alloc.c | 69 +--
1 file changed, 42 insertions(+), 27 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a8e86b5..9c1d680 100644
--- a/mm/page_alloc.c
From: Ankita Garg gargank...@gmail.com
Verify that the zonelists were created appropriately.
Signed-off-by: Ankita Garg gargank...@gmail.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
mm/mm_init.c | 57 ++---
1
From: Ankita Garg gargank...@gmail.com
Change the way vmstats are collected. Since the zones are now present inside
regions, scan through all the regions to obtain zone specific statistics.
Signed-off-by: Ankita Garg gargank...@gmail.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b
From: Ankita Garg gargank...@gmail.com
Modify vmscan to take into account the changed node-zone hierarchy.
Signed-off-by: Ankita Garg gargank...@gmail.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
mm/vmscan.c | 364
memory region size to be 512MB.
In future, we expect ACPI 5.0 compliant firmware to expose the required
info in the form of MPST (Memory Power State Table) tables.
Signed-off-by: Ankita Garg gargank...@gmail.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
mm/page_alloc.c
-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
mm/vmstat.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 86a92a6..b3be9ba 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -179,9 +179,12 @@ void
regions data-structure,
we can influence MM decisions at various places, such as page allocation,
reclamation etc.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/mmzone.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/mmzone.h b
Initialize the node's memory regions structures with the information about
the region-boundaries, at boot time.
Based-on-patch-by: Ankita Garg gargank...@gmail.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/mm.h |4
mm/page_alloc.c| 35
.
ZONE_NORMAL has 2 zone memory regions (say, Zone mem reg 0 and Zone mem reg 1)
which are subsets of Node mem reg 0 and Node mem reg 1 respectively.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/mmzone.h |9 +
mm/page_alloc.c| 42
array would look like this:
node_regions[1].zone_region_idx[ZONE_NORMAL] == 1
Using this index array, we can quickly obtain the zone memory region to
which a given page belongs.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/mm.h | 23
of zone memory regions and counters to track the number of free
pageblocks within each region.
Also, fixup the references to the freelist's list_head inside struct free_area.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/mmzone.h | 17 -
mm
within
a minimal number of regions (approximately).
Increasing region number--
Direction of allocation--- ---Direction of reclaim
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
mm/page_alloc.c | 128
that, and use it to keep the fastpath of page allocation almost as
fast as it would be without memory regions.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/mm.h | 11 ++
include/linux/mmzone.h |6 ++
mm/page_alloc.c| 51
memory region accurately, we
should be able to observe the new page allocator behavior to a reasonable
degree of accuracy.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
mm/vmstat.c | 57 +
1 file changed, 53
On 11/07/2012 04:33 AM, Dave Hansen wrote:
On 11/06/2012 11:52 AM, Srivatsa S. Bhat wrote:
But of course, memory regions are sub-divisions *within* a node, so it makes
sense to keep the data-structures in the node's struct pglist_data. (Thus
this placement makes memory regions parallel
On 11/07/2012 03:19 AM, Dave Hansen wrote:
On 11/06/2012 11:53 AM, Srivatsa S. Bhat wrote:
This is the main change - we keep the pageblocks in region-sorted order,
where pageblocks belonging to region-0 come first, followed by those
belonging
to region-1 and so on. But the pageblocks within
On 11/08/2012 11:32 PM, Mel Gorman wrote:
On Wed, Nov 07, 2012 at 01:22:13AM +0530, Srivatsa S. Bhat wrote:
Today memory subsystems are offer a wide range of capabilities for managing
memory power consumption. As a quick example
Move the check for populated_zone() to the control statement of the
'for' loop and get rid of the odd looking if/else block.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/mmzone.h |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
On 10/19/2012 07:24 PM, Johannes Weiner wrote:
On Fri, Oct 19, 2012 at 04:25:47PM +0530, Srivatsa S. Bhat wrote:
Move the check for populated_zone() to the control statement of the
'for' loop and get rid of the odd looking if/else block.
Signed-off-by: Srivatsa S. Bhat srivatsa.b
Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Michal Hocko mho...@suse.cz
[Srivatsa: Rebased to current mainline]
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
This is a resend of the patch posted by Michal at [1]. Martin had explained
of local_irq_disable(),
hard_irq_disable() and __cpu_disable() somehow managed to wrongly keep the
interrupts still enabled...
Regards,
Srivatsa S. Bhat
That simply doesn't make any sense.
Signed-off-by: Huacai Chen che...@lemote.com
---
kernel/sched/core.c |5 +++--
1 files changed, 3
overhead in the next version and measure
whether its cost vs benefit really works out or not. Thank you very much
for pointing it out!
Regards,
Srivatsa S. Bhat
On Tue, Nov 6, 2012 at 1:53 PM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com
mailto:srivatsa.b...@linux.vnet.ibm.com wrote
cache
(depending on how aggressive we want to get with respect to power-management)
is the way to go?
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
On 11/09/2012 08:21 PM, Srivatsa S. Bhat wrote:
On 11/09/2012 02:30 PM, Mel Gorman wrote:
On Fri, Nov 09, 2012 at 10:44:16AM +0530, Vaidyanathan Srinivasan wrote:
* Mel Gorman mgor...@suse.de [2012-11-08 18:02:57]:
[...]
Short description of the Sorted-buddy design
On 11/09/2012 09:43 PM, Dave Hansen wrote:
On 11/09/2012 07:23 AM, Srivatsa S. Bhat wrote:
FWIW, kernbench is actually (and surprisingly) showing a slight performance
*improvement* with this patchset, over vanilla 3.7-rc3, as I mentioned in
my other email to Dave.
https://lkml.org/lkml/2012
On 11/09/2012 10:04 PM, Srivatsa S. Bhat wrote:
On 11/09/2012 09:43 PM, Dave Hansen wrote:
On 11/09/2012 07:23 AM, Srivatsa S. Bhat wrote:
FWIW, kernbench is actually (and surprisingly) showing a slight performance
*improvement* with this patchset, over vanilla 3.7-rc3, as I mentioned in
my
On 11/09/2012 10:13 PM, Srivatsa S. Bhat wrote:
On 11/09/2012 10:04 PM, Srivatsa S. Bhat wrote:
On 11/09/2012 09:43 PM, Dave Hansen wrote:
On 11/09/2012 07:23 AM, Srivatsa S. Bhat wrote:
FWIW, kernbench is actually (and surprisingly) showing a slight performance
*improvement
Hi Srinivas,
It looks like your email did not get delivered to the mailing
lists (and the people in the CC list) properly. So quoting your
entire mail as-it-is here. And thanks a lot for taking a look
at this patchset!
Regards,
Srivatsa S. Bhat
On 11/09/2012 10:18 PM, SrinivasPandruvada wrote
. Bhat srivatsa.b...@linux.vnet.ibm.com
Regards,
Srivatsa S. Bhat
diff --git a/kernel/printk.c b/kernel/printk.c
index 66a2ea3..2d607f4 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1890,7 +1890,6 @@ static int __cpuinit console_cpu_notify(struct
notifier_block *self,
switch
where CPU0 can go offline?
Regards,
Srivatsa S. Bhat
+static int __init bsp_pm_check_init(void)
+{
+/*
+ * Set this bsp_pm_callback as lower priority than
+ * cpu_hotplug_pm_callback. So cpu_hotplug_pm_callback will be called
+ * earlier to disable cpu hotplug before bsp
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 srivatsa.b...@linux.vnet.ibm.com
---
include/linux/perf_event.h |3 +++
1 file changed, 3 insertions(+)
diff
The perf_cpu_notifier() macro invokes smp_processor_id() multiple
times. Optimize it by using a local variable.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/perf_event.h |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include
in the meantime.
Regards,
Srivatsa S. Bhat
+ break;
+ case PM_POST_RESTORE:
+ /*
+ * When a resume really happens, this code won't be called.
+ *
+ * This code is called only when user space hibernation software
On 10/16/2012 09:47 PM, Rafael J. Wysocki wrote:
On Tuesday 16 of October 2012 11:05:18 Srivatsa S. Bhat wrote:
On 10/16/2012 02:20 AM, Rafael J. Wysocki wrote:
On Friday 12 of October 2012 09:09:42 Fenghua Yu wrote:
From: Fenghua Yu fenghua...@intel.com
+
+/*
+ * When bsp_check
On 10/16/2012 10:01 PM, Paul E. McKenney wrote:
On Tue, Oct 16, 2012 at 01:28:10PM +0530, 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.
Color me confused...
Hehe, I
On 10/17/2012 12:04 AM, Paul E. McKenney wrote:
On Tue, Oct 16, 2012 at 10:07:15PM +0530, Srivatsa S. Bhat wrote:
On 10/16/2012 10:01 PM, Paul E. McKenney wrote:
On Tue, Oct 16, 2012 at 01:28:10PM +0530, Srivatsa S. Bhat wrote:
The CPU_STARTING notifiers are supposed to be run with irqs
don't actually see why cpu_hotplug_pm_callback() should not clear the
cpu_hotplug_disabled flag during PM_RESTORE_PREPARE itself.. if we do that,
we don't have to be *this* careful about -when- we can invoke -which-
function..
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send
of October 2012 11:05:18 Srivatsa S. Bhat wrote:
On 10/16/2012 02:20 AM, Rafael J. Wysocki wrote:
On Friday 12 of October 2012 09:09:42 Fenghua Yu wrote:
From: Fenghua Yu fenghua...@intel.com
fix the bug I
pointed out in my other mail.
Because things like this are often overlooked by people
time.
Is the above problem known? intel graphics card.
Not sure if this is the same problem, but here is a discussion around
a recent commit that broke resume. May be you can try out that patch?
https://lkml.org/lkml/2012/7/16/113
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list
Hi Peter,
On 06/20/2012 03:47 PM, Peter Zijlstra wrote:
On Wed, 2012-06-20 at 15:20 +0530, Srivatsa S. Bhat wrote:
Any thoughts on this patch?
Yeah, I stared at it for a while and got a head-ache.. the idle-balance
part if ok, the rt.c part needs a little more-thinking.
Could you kindly
On 07/18/2012 05:22 PM, Martin Schwidefsky wrote:
On Tue, 13 Mar 2012 14:02:35 +0530
Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote:
On 03/13/2012 01:37 PM, Michal Hocko wrote:
OK, so the updated version of the patch looks like this. I am sorry but
I had time to only compile test
this patchset to? I tried v3.5-rc7, but
got lots of warnings (one shown below) and the watchdog patch did not
apply.
Hi Paul,
This patchset applies cleanly on Thomas' smp/hotplug branch in the -tip
tree.
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line unsubscribe linux
,
Srivatsa S. Bhat
IBM Linux Technology Center
--
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/
,
Srivatsa S. Bhat
IBM Linux Technology Center
--
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 07/19/2012 03:43 AM, Mandeep Singh Baines wrote:
Srivatsa S. Bhat (srivatsa.b...@linux.vnet.ibm.com) wrote:
On 06/23/2012 03:36 AM, Mandeep Singh Baines wrote:
A cpu in the mm_cpumask could go offline before we send the invalidate
IPI causing us to wait forever. Avoid this by only waiting
Hi Paul,
While running a CPU hotplug stress test on v3.5-rc7+
(mainline commit 8a7298b7805ab) I hit this warning.
I haven't tried to debug this yet...
Line number 1550 maps to:
WARN_ON_ONCE(cpu_is_offline(smp_processor_id()));
inside rcu_do_batch().
Regards,
Srivatsa S. Bhat
[ 1206.095436
Singh Baines m...@chromium.org
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Acked-by: Mandeep Singh Baines m...@chromium.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Tejun Heo t
On 07/19/2012 07:02 PM, Borislav Petkov wrote:
On Thu, Jul 19, 2012 at 06:27:33PM +0530, Srivatsa S. Bhat wrote:
[ … ]
So we are sending an IPI to a cpu which is now offline. Once a cpu is
offline,
it will no longer respond to IPIs. This explains the softlockup.
A cpu in the mm_cpumask
that write_update_netdev_table() will handle things
just fine.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
Requesting a thorough review of this patch, since I am not sure whether
removing update_netdev_tables() is perfectly OK and whether that is the
right thing to do.
net/core
Hi Cody,
Thank you for your review comments and sorry for the delay in replying!
On 04/11/2013 04:56 AM, Cody P Schafer wrote:
On 04/09/2013 02:48 PM, Srivatsa S. Bhat wrote:
We need a way to decide when to trigger the worker threads to perform
region evacuation/compaction. So the strategy
we even bother pinning the task to (another)
CPU? Why not just proceed with the reboot?
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
On 04/17/2013 03:33 PM, Robin Holt wrote:
On Wed, Apr 17, 2013 at 09:48:35AM +0200, Ingo Molnar wrote:
* Robin Holt h...@sgi.com wrote:
On Tue, Apr 16, 2013 at 09:18:07PM +0530, Srivatsa S. Bhat wrote:
On 04/16/2013 05:36 PM, Robin Holt wrote:
On Tue, Apr 16, 2013 at 01:32:56PM +0200, Ingo
1 - 100 of 2690 matches
Mail list logo
