On 31.03.2015 [11:48:29 +0200], Michal Hocko wrote:
> On Fri 27-03-15 15:23:50, Nishanth Aravamudan wrote:
> > On 27.03.2015 [13:17:59 -0700], Dave Hansen wrote:
> > > On 03/27/2015 12:28 PM, Nishanth Aravamudan wrote:
> > > > @@ -2585,7 +2585,7 @@ static bool pfm
On 03.04.2015 [09:57:35 +0200], Vlastimil Babka wrote:
> On 03/31/2015 11:48 AM, Michal Hocko wrote:
> >On Fri 27-03-15 15:23:50, Nishanth Aravamudan wrote:
> >>On 27.03.2015 [13:17:59 -0700], Dave Hansen wrote:
> >>>On 03/27/2015 12:28 PM, Nishanth Aravamudan w
On 03.04.2015 [20:24:45 +0200], Michal Hocko wrote:
> On Fri 03-04-15 10:43:57, Nishanth Aravamudan wrote:
> > On 31.03.2015 [11:48:29 +0200], Michal Hocko wrote:
> [...]
> > > I would expect kswapd would be looping endlessly because the zone
> > > wouldn't be
Hi Peter,
As you are very aware, I think, power has some odd NUMA topologies (and
changes to the those topologies) at run-time. In particular, we can see
a topology at boot:
Node 0: all Cpus
Node 7: no cpus
Then we get a notification from the hypervisor that a core (or two) have
moved from node
On 07.04.2015 [12:21:47 +0200], Peter Zijlstra wrote:
> On Mon, Apr 06, 2015 at 02:45:58PM -0700, Nishanth Aravamudan wrote:
> > Hi Peter,
> >
> > As you are very aware, I think, power has some odd NUMA topologies (and
> > changes to the those topologies) at run-time
On 10.04.2015 [14:37:19 +0300], Konstantin Khlebnikov wrote:
> On 10.04.2015 01:58, Tanisha Aravamudan wrote:
> >On 09.04.2015 [07:27:28 +0300], Konstantin Khlebnikov wrote:
> >>On Thu, Apr 9, 2015 at 2:07 AM, Nishanth Aravamudan
> >> wrote:
> >>>On
On 10.04.2015 [11:08:10 +0200], Peter Zijlstra wrote:
> On Fri, Apr 10, 2015 at 10:31:53AM +0200, Peter Zijlstra wrote:
> > Please, step back, look at what you're doing and ask yourself, will any
> > sane person want to use this? Can they use this?
> >
> > If so, start by describing the desired us
On 10.04.2015 [10:31:53 +0200], Peter Zijlstra wrote:
> On Thu, Apr 09, 2015 at 03:29:56PM -0700, Nishanth Aravamudan wrote:
> > > No, that's very much not the same. Even if it were dealing with hotplug
> > > it would still assume the cpu to return to the same node.
>
On 08.04.2015 [20:04:04 +0300], Konstantin Khlebnikov wrote:
> On 08.04.2015 19:59, Konstantin Khlebnikov wrote:
> >Node 0 might be offline as well as any other numa node,
> >in this case kernel cannot handle memory allocation and crashes.
Isn't the bug that numa_node_id() returned an offline node
On 03.04.2015 [10:45:56 -0700], Nishanth Aravamudan wrote:
> On 03.04.2015 [09:57:35 +0200], Vlastimil Babka wrote:
> > On 03/31/2015 11:48 AM, Michal Hocko wrote:
> > >On Fri 27-03-15 15:23:50, Nishanth Aravamudan wrote:
> > >>On 27.03.2015 [13:17:59 -0700], Dave
On 08.05.2015 [15:47:26 -0700], Andrew Morton wrote:
> On Wed, 06 May 2015 11:28:12 +0200 Vlastimil Babka wrote:
>
> > On 05/06/2015 12:09 AM, Nishanth Aravamudan wrote:
> > > On 03.04.2015 [10:45:56 -0700], Nishanth Aravamudan wrote:
> > >>> What I find somew
Hi Nathan,
On 26.08.2014 [08:10:14 -0500], Nathan Fontenot wrote:
> On 08/25/2014 02:22 AM, Li Zhong wrote:
> > With commit 2fabf084b, during boottime, cpu_numa_callback() is called
> > earlier(before their online) for each cpu, and verify_cpu_node_mapping()
> > uses cpu_to_node() to check whether
(which
> will be set up in smp_prepare_cpus()).
>
> So I saw something like following reported:
> [0.00] CPU thread siblings 1/2/3 and 0 don't belong to the same
> node!
>
> As we don't actually do the checking during this early stage, so maybe
> we could dir
o set up
> numa information only on present cpus.
>
> For those possible, but not present cpus, their numa information
> will be set up after they are started, as the original code did before commit
> 2fabf084b6ad.
>
> Cc: Nishanth Aravamudan
> Cc: Nathan Fontenot
> Si
et correct numa information for it.
>
> if the cpu is present, then we set the first online node to
> numa_cpu_lookup_table instead of 0 ( in case 0 might not be an online node? )
Not currently possible (Node 0 is always online), but I'm working on
changing that :)
>
> Cc
Anton noticed (http://www.spinics.net/lists/linux-mm/msg67489.html) that
on ppc LPARs with memoryless nodes, a large amount of memory was
consumed by slabs and was marked unreclaimable. He tracked it down to
slab deactivations in the SLUB core when we allocate remotely, leading
to poor efficiency a
will
return a node Y with memory that has the nearest distance. If X is
memoryless node, it will return nearest distance node, but, if X is
normal node, it will return itself.
We will use this function in following patch to determine the fallback
node.
Signed-off-by: Joonsoo Kim
Signed-off-by: Nis
-by: Joonsoo Kim
Signed-off-by: Nishanth Aravamudan
---
v1 -> v2 (Nishanth):
Add commit message
Clean-up conditions in get_partial()
diff --git a/mm/slub.c b/mm/slub.c
index 3e8afcc07a76..497fdfed2f01 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1699,7 +1699,12 @@ static void *get_partial(str
_node() to determine the fallback node" and "slub: fallback
to node_to_mem_node() node if allocating on memoryless node") adding and
using node_to_mem_node(), we can safely undo part of the change to the
kthread logic from 81c98869faa5.
Signed-off-by: Nishanth Aravamudan
diff --git a/
level of such functionality, similar to the numa=
command-line parameter.
Signed-off-by: Nishanth Aravamudan
---
This is pretty rough, but has been useful in the field already. I'm not
sure if more information would be useful than this basic amount.
diff --git a/Documentation/k
On 09.09.2014 [17:11:15 -0700], Andrew Morton wrote:
> On Tue, 9 Sep 2014 12:03:27 -0700 Nishanth Aravamudan
> wrote:
>
> > From: Joonsoo Kim
> >
> > We need to determine the fallback node in slub allocator if the
> > allocation target node is memoryless n
On 09.09.2014 [17:11:25 -0700], Andrew Morton wrote:
> On Tue, 9 Sep 2014 12:05:14 -0700 Nishanth Aravamudan
> wrote:
>
> > From: Joonsoo Kim
> >
> > Update the SLUB code to search for partial slabs on the nearest node
> > with memory in the presence of memor
On 10.09.2014 [12:06:16 -0700], Andrew Morton wrote:
> On Tue, 9 Sep 2014 17:47:23 -0700 Nishanth Aravamudan
> wrote:
>
> > On 09.09.2014 [17:11:15 -0700], Andrew Morton wrote:
> > > On Tue, 9 Sep 2014 12:03:27 -0700 Nishanth Aravamudan
> > > wrote:
Hi Michael,
On 15.09.2014 [15:05:36 +1000], Michael Ellerman wrote:
> On Tue, 2014-09-09 at 13:09 -0700, Nishanth Aravamudan wrote:
> > We have hit a few customer issues with the topology update code (VPHN
> > and PRRN). It would be nice to be able to debug the notifications comi
On 16.09.2014 [14:42:20 -0500], Nathan Fontenot wrote:
>
>
> On 09/09/2014 03:09 PM, Nishanth Aravamudan wrote:
> > We have hit a few customer issues with the topology update code (VPHN
> > and PRRN). It would be nice to be able to debug the notifications coming
> >
actually do the checking during this early stage, so maybe
> we could directly call numa_setup_cpu() in do_init_bootmem().
>
> Cc: Nishanth Aravamudan
> Cc: Nathan Fontenot
> Signed-off-by: Li Zhong
> ---
> arch/powerpc/mm/numa.c | 3 +--
> 1 file changed, 1 insertion(+
On 03.10.2014 [07:28:19 +1000], Benjamin Herrenschmidt wrote:
> On Thu, 2014-10-02 at 14:13 -0700, Nishanth Aravamudan wrote:
> > Ben & Michael,
> >
> > What's the status of these patches?
>
> Waiting for somebody to review them ? :-)
Heh, I acked them abou
On 02.10.2014 [23:59:15 +0200], Greg Kurz wrote:
> The associativity domain numbers are obtained from the hypervisor through
> registers and written into memory by the guest: the packed array passed to
> vphn_unpack_associativity() is then native-endian, unlike what was assumed
> in the following c
On 03.10.2014 [10:50:20 +1000], Michael Ellerman wrote:
> On Thu, 2014-10-02 at 14:13 -0700, Nishanth Aravamudan wrote:
> > Ben & Michael,
> >
> > What's the status of these patches?
>
> Been in my next for a week :)
>
> https://git.kernel.org/cgit/linu
alues. This leads to severe performance breakdowns.
>
> This patch does two things:
> - extract values from the packed array with shifts, in order to be endian
> neutral
> - convert the resulting values to be32 as expected
>
> Suggested-by: Anton Blanchard
> Signed-
On 07.10.2014 [17:28:38 +1100], Michael Ellerman wrote:
> On Fri, 2014-10-03 at 16:26 -0700, Nishanth Aravamudan wrote:
> > On 03.10.2014 [10:50:20 +1000], Michael Ellerman wrote:
> > > On Thu, 2014-10-02 at 14:13 -0700, Nishanth Aravamudan wrote:
> > > > Ben & Mi
ot or very shortly after coming to login,
and have resulted in a broken NUMA topology.
Signed-off-by: Nishanth Aravamudan
---
v1 -> v2:
Updated commit message to answer some of mpe's reviews.
Switched to pr_fmt based debugging, which removes the need for the
debug flag.
Be a little le
proc_create can fail, we should check the return value and pass up the
failure.
Suggested-by: Michael Ellerman
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index d7737a542fd7..e28c21ba862d 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc
On 10.10.2014 [15:28:16 +1100], Michael Ellerman wrote:
> On Thu, 2014-09-10 at 23:42:15 UTC, Nishanth Aravamudan wrote:
> > We have hit a few customer issues with the topology update code (VPHN
> > and PRRN). It would be nice to be able to debug the notifications coming
> > f
There isn't any need to keep referring to update->cpu, as we've already
checked cpu == update->cpu at this point.
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 649666d5d1c2..86fdb004ad2f 100644
--- a/arch/powerpc/mm/n
topology in the per-cpu maps. Ensure that we update the per-cpu
fields when we re-map CPUs.
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 86fdb004ad2f..048be62dc979 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1488,11
Hi Michael,
On 21.10.2014 [15:36:27 +1100], Michael Ellerman wrote:
> On Sat, 2014-18-10 at 00:50:40 UTC, Nishanth Aravamudan wrote:
> > We received a report of warning in kernel/sched/core.c where the sched
> > group was NULL on an LPAR after a topology update. This seems to oc
Now that we have AT_HWCAP2 support, start exposing some of the new
POWER8 features via it.
Signed-off-by: Nishanth Aravamudan
---
Note: there are, I think, some Freescale processors that also should be
updated to indicate they support ISEL, but I don't know which ones.
Since this is
On 04.05.2013 [09:23:51 +1000], Benjamin Herrenschmidt wrote:
> On Fri, 2013-05-03 at 16:19 -0700, Nishanth Aravamudan wrote:
> > +/* in AT_HWCAP2 */
> > +#define PPC_FEATURE2_ARCH_2_07 0x8000
> > +#define PPC_FEATURE2_HTM 0x4000
> >
Also, make HTM's presence dependent on the .config option.
Signed-off-by: Nishanth Aravamudan
---
Changes since v1:
- Add TAR.
- Make HTM config dependent.
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index fcc54ad..26807e5 100644
--- a
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index ae9f433..a792157 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -98,6 +98,7 @@ extern void __restore_cpu_e6500(void
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index a792157..b224cd5 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1999,6 +1999,7 @@ static struct cpu_spec __initdata cpu_specs
Signed-off-by: Nishanth Aravamudan
---
Changes since v1:
- Add TAR.
- Use config dependent symbol for HTM.
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index b224cd5..79cde71 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
Signed-off-by: Nishanth Aravamudan
---
Changes since v2:
- Added e5500 per Segher.
I've not added POWER7 yet, as I'm waiting to confirm with others on
that. I will send it as a follow-up patch if needed.
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputab
On 07.05.2013 [07:37:08 +1000], Benjamin Herrenschmidt wrote:
> On Mon, 2013-05-06 at 09:38 -0500, Ryan Arnold wrote:
> > My understanding was that these bits being 'on' is an indication of
> > what features the hardware supports (or what the kernel emulates) and
> > a not an indication of whether
On 08.05.2013 [06:49:38 +1000], Benjamin Herrenschmidt wrote:
> On Tue, 2013-05-07 at 13:33 -0700, Nishanth Aravamudan wrote:
> > > Similarily, Nish, you may need to check that we remove those bits if
> > > pHyp has the partition in a mode that doesn't support them (
r" type, instead.
The raw entry also should be updated, as "ppc64/ibm-compat-v1" indicates
to oprofile userspace to use "compatibility events" which are obsolete
in ISA 2.07.
Signed-off-by: Nishanth Aravamudan
---
Ben, if this seems reasonable to you, it would be great to get
On 12.06.2015 [16:47:03 +1000], Gavin Shan wrote:
> On Fri, Jun 12, 2015 at 04:19:17PM +1000, Alexey Kardashevskiy wrote:
> >The existing code puts all devices from a root PE to the same IOMMU group.
> >However it is a possible situation when subordinate buses belong to
> >separate PEs, in this cas
On 24.06.2015 [07:13:36 -0500], Nathan Fontenot wrote:
> On 06/23/2015 11:01 PM, Bharata B Rao wrote:
> > So will it be correct to say that memory hotplug to memory-less node
> > isn't supported by PowerPC kernel ? Should I enforce the same in QEMU
> > for PowerKVM ?
> >
>
> I'm not sure if that i
Currently, on a LPAR with the nx-842 device disabled, the following
messages are emitted:
nx_compress: no nx842 driver found. [1]
Registering IBM Power 842 compression driver
nx_compress_pseries ibm,compression-v1: nx842_OF_upd_status: status 'disabled'
is not 'okay'
nx_compress_pseries ibm,compr
extra error in that case. It seems
like the proper return code of a disabled device is ENODEV.
Signed-off-by: Nishanth Aravamudan
---
drivers/crypto/nx/nx-842-pseries.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/nx/nx-842-pseries.c
b/drivers/crypto/nx/nx
While there is no technical reason that both nx-842.c and
nx-842-pseries.c can have the same name for the init/exit functions, it
is a bit confusing with initcall_debug. Rename the pseries specific
functions appropriately
Signed-off-by: Nishanth Aravamudan
---
drivers/crypto/nx/nx-842
en that 'disabled' is a valid state, and we are going to emit that
the device is disabled, only print out a non-'okay' status if it is not
'disabled'.
Signed-off-by: Nishanth Aravamudan
---
drivers/crypto/nx/nx-842-pseries.c | 8 +++-
1 file changed, 7 in
never be found. Similar pseries
messages are printed on powernv.
Signed-off-by: Nishanth Aravamudan
---
drivers/crypto/nx/nx-842-powernv.c | 6 ++
drivers/crypto/nx/nx-842-pseries.c | 6 ++
drivers/crypto/nx/nx-842.h | 1 +
3 files changed, 13 insertions(+)
diff --git a/drivers
Currently, when the nx-842-pseries driver loads, the following message
is emitted:
alg: No test for 842 (842-nx)
It seems like the simplest way to fix this message (other than adding a
proper test) is to just insert the null test into the list in the
testmgr.
Signed-off-by: Nishanth Aravamudan
platform driver.
Signed-off-by: Nishanth Aravamudan
Cc: Dan Streetman
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/crypto/nx/nx-842-platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
di
c: [0] 0 1 2 3 [1] 4 5 6 7
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index 5f1048e..f2c4c89 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -39,6 +39,8 @@ static inlin
A simple move to a wrapper function to numa_cpu_lookup_table, now that
power has the early_cpu_to_node() API.
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index ec9ec20..7bf333b 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc
On 03.07.2015 [11:30:32 +1000], Michael Ellerman wrote:
> On Thu, 2015-07-02 at 15:40 -0700, Nishanth Aravamudan wrote:
> > While we never would successfully load on the wrong machine type, there
> > is extra output by default regardless of machine type.
> >
> > For
On 06.07.2015 [16:13:07 +0800], Herbert Xu wrote:
> On Thu, Jul 02, 2015 at 03:42:26PM -0700, Nishanth Aravamudan wrote:
> > Based off the CONFIG_SPU_FS_MODULE code, only attempt to load platform
> > modules if the nx-842 pseries/powernv drivers are built as modules.
> &g
On 08.07.2015 [14:00:56 +1000], Michael Ellerman wrote:
> On Thu, 2015-02-07 at 23:02:02 UTC, Nishanth Aravamudan wrote:
> > Much like on x86, now that powerpc is using USE_PERCPU_NUMA_NODE_ID, we
> > have an ordering issue during boot with early calls to cpu_to_node().
>
>
On 08.07.2015 [16:16:23 -0700], Nishanth Aravamudan wrote:
> On 08.07.2015 [14:00:56 +1000], Michael Ellerman wrote:
> > On Thu, 2015-02-07 at 23:02:02 UTC, Nishanth Aravamudan wrote:
> > > Much like on x86, now that powerpc is using USE_PERCPU_NUMA_NODE_ID, we
> > > ha
On 08.07.2015 [18:22:09 -0700], David Rientjes wrote:
> On Thu, 2 Jul 2015, Nishanth Aravamudan wrote:
>
> > Much like on x86, now that powerpc is using USE_PERCPU_NUMA_NODE_ID, we
> > have an ordering issue during boot with early calls to cpu_to_node().
> > The value ret
On 04.07.2015 [15:24:53 +0800], Herbert Xu wrote:
> On Thu, Jul 02, 2015 at 03:41:19PM -0700, Nishanth Aravamudan wrote:
> > Currently, when the nx-842-pseries driver loads, the following message
> > is emitted:
> >
> > alg: No test for 842 (842-nx)
> >
> >
On 13.07.2015 [17:05:36 -0700], Nishanth Aravamudan wrote:
> On 04.07.2015 [15:24:53 +0800], Herbert Xu wrote:
> > On Thu, Jul 02, 2015 at 03:41:19PM -0700, Nishanth Aravamudan wrote:
> > > Currently, when the nx-842-pseries driver loads, the following message
> > > i
On 15.07.2015 [16:35:16 -0400], Tejun Heo wrote:
> Hello,
>
> On Thu, Jul 02, 2015 at 04:02:02PM -0700, Nishanth Aravamudan wrote:
> > we currently emit at boot:
> >
> > [0.00] pcpu-alloc: [0] 0 1 2 3 [0] 4 5 6 7
> >
> > After this commit, we
On 21.07.2015 [10:32:34 -0500], Chris J Arges wrote:
> Some architectures like POWER can have a NUMA node_possible_map that
> contains sparse entries. This causes memory corruption with openvswitch
> since it allocates flow_cache with a multiple of num_possible_nodes() and
Couldn't this also be fi
tch node_online_map on boot.
> Fixes: 3af229f2071f5b5cb31664be6109561fbe19c861
>
> Signed-off-by: Chris J Arges
Acked-by: Nishanth Aravamudan
> ---
> net/openvswitch/flow_table.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/flow_tab
On 21.07.2015 [11:30:58 -0500], Chris J Arges wrote:
> On Tue, Jul 21, 2015 at 09:24:18AM -0700, Nishanth Aravamudan wrote:
> > On 21.07.2015 [10:32:34 -0500], Chris J Arges wrote:
> > > Some architectures like POWER can have a NUMA node_possible_map that
> > > contains
Under heavy (DLPAR?) stress, we tripped this panic() in
arch/powerpc/kernel/iommu.c::iommu_init_table():
page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
if (!page)
panic("iommu_init_table: Can't allocate %ld bytes\n",
sz);
Before the panic() we got a page
ot been able to
reproduce the panic.
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 0adab06..572bb5b 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -661,7 +661,7 @@ struct iommu_table *iommu_init
: Nishanth Aravamudan
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index e2685ba..a55b685 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -382,6 +382,7 @@ static int tce_clearrange_multi_pSeriesLP
ls. Fix this by calling remove_ddw() first, which will
unmap the DDW TCEs.
Note: a corresponding change to drmgr is needed to actually successfully
DLPAR, such that the device-tree update (which causes the notifier chain
to fire) occurs before slot isolate.
Signed-off-by: Nishanth Aravamudan
di
The parameter is unused, and complicates a following fix. Just remove
it.
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index b4bb9e1..a8e99f9 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch
on").
I believe the simplest, easiest-to-maintain fix is to just change our
initcall to, rather than detecting and updating the new kernel's DDW
knowledge, just remove all DDW configurations. When the drivers
re-initialize, we will set everything back up as it was before.
Signed-off-by
Hi Michael,
On 29.01.2013 [21:58:28 +1100], Michael Ellerman wrote:
> On Mon, 2013-01-28 at 18:03 -0800, Nishanth Aravamudan wrote:
> > pseries/iommu: remove DDW on kexec
> > ...
> >
> > I believe the simplest, easiest-to-maintain fix is to just change our
&
t
doing any DDW manipulation.
Signed-off-by: Nishanth Aravamudan
---
This is pretty ugly, but I couldn't immediately see a better solution.
In particular, I'm not sure there is much we can do if the kzalloc
fails, so I just have it return as normal.
diff --git a/arch/powerpc/platform
From: Michael Neuling
We are currently out of free bits in AT_HWCAP. With POWER8, we have
several hardware features that we need to advertise. Tested on POWER and
x86.
Signed-off-by: Michael Neuling
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch
Hi Christoph,
Sorry for the delay in my response!
On 03.04.2014 [11:41:37 -0500], Christoph Lameter wrote:
> On Mon, 31 Mar 2014, Nishanth Aravamudan wrote:
>
> > Yep. The node exists, it's just fully exhausted at boot (due to the
> > presence of 16GB pages reserved at b
there must be no partial slab on that node.
>
> On that node, page allocation always fallback to numa_mem_id() first. So
> searching a partial slab on numa_node_id() in that case is proper solution
> for memoryless node case.
>
> Signed-off-by: Joonsoo Kim
Acked-by: Nishanth A
Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
topology tracking, specifically:
initialize per cpu numa_node entry in start_secondary
remove the powerpc cpu_to_node()
define CONFIG_USE_PERCPU_NUMA_NODE_ID if NUMA
Signed-off-by: Nishanth
: 31744 kB
SUnreclaim: 267200 kB
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9125964..bd6dd6e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -457,6 +457,10 @@ config USE_PERCPU_NUMA_NODE_ID
def_bool y
Hi Andrew,
I found one issue with my patch, fixed below...
On 16.05.2014 [16:39:45 -0700], Nishanth Aravamudan wrote:
> Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
> topology tracking, specifically:
>
> initialize per cpu numa_node entry in sta
On 13.03.2014 [09:49:49 -0700], Nishanth Aravamudan wrote:
> On 12.03.2014 [08:41:40 -0500], Christoph Lameter wrote:
> > On Tue, 11 Mar 2014, Nishanth Aravamudan wrote:
> > > I have a P7 system that has no node0, but a node0 shows up in numactl
> > > --hardware, whic
Hi Tejun,
On 21.05.2014 [14:58:12 -0400], Tejun Heo wrote:
> Hello,
>
> On Wed, May 21, 2014 at 09:16:27AM -0500, Christoph Lameter wrote:
> > On Mon, 19 May 2014, Nishanth Aravamudan wrote:
> > > I'm seeing a panic at boot with this change on an LPAR which actuall
Hi Srivatsa,
After d4edc5b6 ("powerpc: Fix the setup of CPU-to-Node mappings during
CPU online"), cpu_to_node() looks like:
static inline int cpu_to_node(int cpu)
{
int nid;
nid = numa_cpu_lookup_table[cpu];
/*
* During early boot, the numa-cpu lookup table migh
On 19.05.2014 [11:14:23 -0700], Nishanth Aravamudan wrote:
> Hi Andrew,
>
> I found one issue with my patch, fixed below...
>
> On 16.05.2014 [16:39:45 -0700], Nishanth Aravamudan wrote:
> > Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
On 28.05.2014 [09:56:14 +1000], Benjamin Herrenschmidt wrote:
> On Tue, 2014-05-27 at 16:44 -0700, Nishanth Aravamudan wrote:
> > > Signed-off-by: Nishanth Aravamudan
> >
> > Ping on this and patch 2/2. Ben, would you be willing to pull these
> > into
> >
On 23.05.2014 [02:18:05 +0530], Srivatsa S. Bhat wrote:
>
> [ Adding a few more CC's ]
>
> On 05/22/2014 01:34 AM, Nishanth Aravamudan wrote:
> > Hi Srivatsa,
> >
> > After d4edc5b6 ("powerpc: Fix the setup of CPU-to-Node mappings during
&g
On 28.05.2014 [16:36:07 -0700], Andrew Morton wrote:
> On Tue, 27 May 2014 17:09:58 -0700 Nishanth Aravamudan
> wrote:
>
> > On 28.05.2014 [09:56:14 +1000], Benjamin Herrenschmidt wrote:
> > > On Tue, 2014-05-27 at 16:44 -0700, Nishanth Aravamudan wrote:
> >
On 09.06.2014 [14:38:26 -0700], David Rientjes wrote:
> On Fri, 23 May 2014, Srivatsa S. Bhat wrote:
>
> > diff --git a/arch/powerpc/include/asm/topology.h
> > b/arch/powerpc/include/asm/topology.h
> > index c920215..58e6469 100644
> > --- a/arch/powerpc/include/asm/topology.h
> > +++ b/arch/powe
On 09.06.2014 [14:47:57 -0700], David Rientjes wrote:
> On Wed, 21 May 2014, Nishanth Aravamudan wrote:
>
> > For context: I was looking at why N_ONLINE was statically setting Node 0
> > to be online, whether or not the topology is that way -- I've been
> > getting s
On 21.05.2014 [14:58:12 -0400], Tejun Heo wrote:
> Hello,
>
> On Wed, May 21, 2014 at 09:16:27AM -0500, Christoph Lameter wrote:
> > On Mon, 19 May 2014, Nishanth Aravamudan wrote:
> > > I'm seeing a panic at boot with this change on an LPAR which actually
> > &
On 19.06.2014 [10:59:50 -0400], Tejun Heo wrote:
> On Tue, Jun 10, 2014 at 04:31:57PM -0700, Nishanth Aravamudan wrote:
> > > I think what this really wants to do is NODE_DATA(cpu_to_mem(cpu)) and I
> > > thought ppc had the cpu-to-local-memory-node mappings correct?
>
[Apologies for the large Cc list, but I believe we have the following
interested parties:
x86 (recently posted memoryless node support)
ia64 (existing memoryless node support)
ppc (existing memoryless node support)
previous discussion of how to solve Anton's issue with slab usage
workqueue contrib
In the presence of memoryless nodes, the workqueue code incorrectly uses
cpu_to_node() to determine what node to prefer memory allocations come
from. cpu_to_mem() should be used instead, which will use the nearest
NUMA node with memory.
Signed-off-by: Nishanth Aravamudan
diff --git a/kernel
USE_PERCPU_NUMA_NODE_ID"). Those commits also
helped improve memory consumption with these kind of environments.
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 51a3ff7..91ff531 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powe
On 10.02.2014 [10:09:36 +0900], Joonsoo Kim wrote:
> On Sat, Feb 08, 2014 at 01:57:39AM -0800, David Rientjes wrote:
> > On Fri, 7 Feb 2014, Joonsoo Kim wrote:
> >
> > > > It seems like a better approach would be to do this when a node is
> > > > brought
> > > > online and determine the fallback
Hi David,
On 21.07.2014 [18:16:58 -0700], David Rientjes wrote:
> On Mon, 21 Jul 2014, Nishanth Aravamudan wrote:
>
> > Sorry for bringing up this old thread again, but I had a question for
> > you, David. node_to_mem_node(), which does seem like a useful API,
> > doesn
On 22.07.2014 [14:43:11 -0700], Nishanth Aravamudan wrote:
> Hi David,
> on powerpc now, things look really good. On a KVM instance with the
> following topology:
>
> available: 2 nodes (0-1)
> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
&
1 - 100 of 386 matches
Mail list logo
