* Ingo Molnar mi...@kernel.org [2012-06-06 11:40:15]:
* Ananth N Mavinakayanahalli ana...@in.ibm.com wrote:
On Wed, Jun 06, 2012 at 11:23:52AM +0200, Peter Zijlstra wrote:
On Wed, 2012-06-06 at 14:49 +0530, Ananth N Mavinakayanahalli wrote:
+int arch_uprobe_analyze_insn(struct
* Oleg Nesterov o...@redhat.com [2012-06-06 17:08:48]:
On 06/06, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
On RISC architectures like powerpc, instructions are fixed size.
Instruction analysis on such platforms is just a matter of (insn % 4).
Well, IMHO, this is confusing.
First of all, why do we have this addr or even vaddr? It should
not exists. We pass it to copy_insn(), but for what?? copy_insn()
should simply use uprobe-offset, the virtual address for this
particular mapping does not matter at all. I am going to send
the
* Oleg Nesterov o...@redhat.com [2012-06-13 21:15:19]:
On 06/12, Oleg Nesterov wrote:
On 06/12, Srikar Dronamraju wrote:
Note also that we should move this !UPROBE_COPY_INSN from
install_breakpoint() to somewhere near alloc_uprobe(). This code
is called only once, it looks
).
The trap_nr addition patch is a prereq.
Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
These seem to be duplicated in kprobes.h, can we consolidate them.
+struct arch_uprobe {
+ u8 insn[MAX_UINSN_BYTES];
+};
Why not uprobe_opcode_t insn ?
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for different archs.
* Oleg Nesterov o...@redhat.com [2012-08-23 11:02:09]:
On 08/23, Benjamin Herrenschmidt wrote:
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for different archs
* Benjamin Herrenschmidt b...@kernel.crashing.org [2012-08-23 20:06:18]:
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for different archs.
uprobe_opcode_t
represents
-nr_cpus_allowed = cpumask_weight(new_mask);
+ cpumask_and(p-cpus_allowed, p-sys_allowed, new_mask);
+ p-nr_cpus_allowed = cpumask_weight(p-cpus_allowed);
}
/*
--
1.8.3.1
--
Thanks and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
this be
if (cpu_online(core * threads_per_core + thr))
cpumask_set_cpu(core * threads_per_core + thr,
stop_cpus);
?
--
Thanks and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
Linuxppc-dev
}
if (!uprobe)
- *is_swbp = is_swbp_at_addr(mm, bp_vaddr);
+ *is_swbp = is_trap_at_addr(mm, bp_vaddr);
} else {
*is_swbp = -EFAULT;
}
--
Thanks and Regards
Srikar Dronamraju
;
ret = arch_uprobe_analyze_insn(uprobe-arch, mm, vaddr);
--
Thanks and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
doesn't understand that the trap was inserted
by some other entity and a SIGTRAP needs to be delivered.
Teach uprobes to ignore breakpoints that do not belong to it.
Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
arch
ana...@in.ibm.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
arch/powerpc/kernel/uprobes.c |6 --
1 file changed, 6 deletions(-)
Index: linux-3.9-rc3/arch/powerpc/kernel/uprobes.c
===
--- linux-3.9-rc3
nothing to wake up
was the commit thats causing the threads to be stuck in futex.
I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and
confirmed that
reverting the commit solved the problem.
--
Thanks and Regards
Srikar Dronamraju
means running more instances of java), the
problem is not seen. I kind of guess, the lesser the number of java
instances the easier it is to reproduce.
--
Thanks and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Is there any other information that I provide that can help?
--
Thanks and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
=b0c29f79ecea0b6fbcefc999
are the same.
Or am I missing something?
--
Thanks and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
reverted commits 99b60ce6 and b0c29f79. Then applied the patches in
the above url. The last one had a reject but it was pretty
straightforward to resolve it. After this, specjbb completes.
So reverting and applying v3 3/4 and 4/4 patches works for me.
--
Thanks and Regards
Srikar Dronamraju
).
--
Thanks and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
#define cpupid_match_pid(task, cpupid) __cpupid_match_pid(task-pid,
cpupid)
757 #ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
(gdb)
However this doesnt seem to happen if we have CONFIG_SPARSEMEM_VMEMMAP=y set in
the config.
--
Thanks nnn Regards
Srikar Dronamraju
With this change, helpers such as instruction_pointer() et al, get defined
in the generic header in terms of GET_IP
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com
---
arch/powerpc/include/asm/ptrace.h | 22
* Mike Frysinger vap...@gentoo.org [2012-02-02 11:28:46]:
On Thursday 02 February 2012 09:41:25 Srikar Dronamraju wrote:
+#define GET_FP(regs) (0)
+#define SET_FP(regs, val)
ppc doesn't have a standard FP location ?
+#define profile_pc(regs) GET_IP(regs)
pretty sure
With this change, helpers such as instruction_pointer() et al, get defined
in the generic header in terms of GET_IP
Removed the unnecessary definition of profile_pc in !CONFIG_SMP case as
suggested by Mike Frysinger.
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off
the __weak changes and
they look good to me.
- Arnaldo
--
Thanks and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
t; Signed-off-by: Anton Blanchard <an...@samba.org>
Works for me too.
Reported-and-Tested-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
--
Thanks and Regards
Srikar Dronamraju
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Fadump kernel reserves significant number of memory blocks. On a multi-node
machine, with CONFIG_DEFFERRED_STRUCT_PAGE support, fadump kernel fails to
boot. Fix this by disabling deferred page struct initialisation.
Signed-off-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
---
arch/p
the first approach.
Srikar Dronamraju (2):
mm: Allow disabling deferred struct page initialisation
fadump: Disable deferred page struct initialisation
arch/powerpc/kernel/fadump.c | 1 +
include/linux/mmzone.h | 2 +-
mm/page_alloc.c | 20
3 files
] [c0ac4014] start_kernel+0x50c/0x578
[c108ff90] [c0008c6c] start_here_common+0x20/0xa8
Allow such kernels to disable deferred page struct initialisation.
Signed-off-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
---
include/linux/mmzone.h | 2 +-
mm/page_alloc.c
* Dave Hansen <dave.han...@intel.com> [2016-08-02 11:09:21]:
> On 08/02/2016 06:19 AM, Srikar Dronamraju wrote:
> > Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialise
> > only certain size memory per node. The certain size takes into account
> >
actice given the relative
> size of the initrd and memory on most systems. But possibly there are
> other things that get reserved and then freed which could skew the hash
> table size calculation.
>
--
Thanks and Regards
Srikar Dronamraju
* Dave Hansen <dave.han...@intel.com> [2016-08-03 11:17:43]:
> On 08/02/2016 11:38 PM, Srikar Dronamraju wrote:
> > * Dave Hansen <dave.han...@intel.com> [2016-08-02 11:09:21]:
> >> On 08/02/2016 06:19 AM, Srikar Dronamraju wrote:
> >>> Kernels comp
net>
Signed-off-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
---
arch/powerpc/kernel/fadump.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 3cb3b02a..eae547d 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/po
ree. Will redo and send out.
>
> --
> Mel Gorman
> SUSE Labs
>
--
Thanks and Regards
Srikar Dronamraju
* Michael Ellerman <m...@ellerman.id.au> [2016-08-10 16:57:57]:
> Srikar Dronamraju <sri...@linux.vnet.ibm.com> writes:
>
> >>
> >> > Conceptually it would be cleaner, if expensive, to calculate the real
> >> > memblock reserves if H
mem 0x1b5dd000-0x1d5d2fff]
[0.00] node 15: [mem 0x1d5d3000-0x1f5c8fff]
The config has the below.
CONFIG_ZONE_DMA32=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_FORCE_MAX_ZONEORDER=9
CONFIG_ZONE_DMA=y
I tried forcing CONFIG_ZONE_DMA to be not set, but make always pick it.
>From source arch/powerpc/Kconfig marks CONFIG_ZONE_DMA as "default y"
--
Thanks and Regards
Srikar Dronamraju
* Mel Gorman <mgor...@techsingularity.net> [2016-08-05 07:47:47]:
> On Thu, Aug 04, 2016 at 10:42:08PM +0530, Srikar Dronamraju wrote:
> > Expand the scope of the existing dma_reserve to accommodate other memory
> > reserves too. Accordingly rename variable dma_reserve to
* Michael Ellerman <m...@ellerman.id.au> [2016-08-05 17:07:01]:
> Srikar Dronamraju <sri...@linux.vnet.ibm.com> writes:
>
> > Fadump kernel reserves large chunks of memory even before the pages are
> > initialized. This could mean memory that corresponds t
gor...@techsingularity.net>
Signed-off-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
---
arch/x86/kernel/e820.c | 2 +-
include/linux/mm.h | 2 +-
mm/page_alloc.c| 20
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/e
net>
Signed-off-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
---
arch/powerpc/kernel/fadump.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 3cb3b02a..ca5ec88 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/po
31220 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 31969280 pages, LIFO batch:1
--
Thanks and Regards
Srikar Dronamraju
> mm, vmscan: Only allocate and reclaim from zones with pages managed by the
> buddy allocator
>
> Firmware Assisted Dump (FA_DUMP) on ppc64 reserves substantial amounts
> of memory when booting a secondary kernel. Srikar Dronamraju reported that
> multiple nodes may have
(struct zone *zone)
> {
> - return (!!zone->present_pages);
> + return (!!zone->managed_pages);
> }
>
> extern int movable_zone;
>
This indeed fixes the problem.
Please add my
Tested-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
afe
- 14.55% zone_watermark_ok_safe
11.38% _find_next_bit.part.0
3.06% find_next_bit
- 11.03% 0.00% [kernel] [k] zone_balanced
- zone_balanced
- zone_watermark_ok_safe
145.84% zone_watermark_ok_safe
11.31% _find_next_bit.part.0
3.04% find_next_bit
--
Thanks and Regards
Srikar Dronamraju
ved memory.
Hence please drop the v2 patches.
--
Thanks and Regards
Srikar Dronamraju
ed-by: Mel Gorman <mgor...@techsingularity.net>
Signed-off-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
---
include/linux/mm.h | 3 +++
mm/page_alloc.c| 12
2 files changed, 15 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 08ed53e
tion.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Mahesh Salgaonkar <mah...@linux.vnet.ibm.com>
Cc: Hari Bathini <hbath...@linux.vnet.ibm.com>
Cc: Dave Hansen <dave.han...@intel.com>
Cc: Balbir Singh <bsinghar...@gmail.com>
Cc:
vnet.ibm.com>
Cc: Dave Hansen <dave.han...@intel.com>
Cc: Balbir Singh <bsinghar...@gmail.com>
Suggested-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
---
include/linux/memblock.h | 1 +
mm/memblock.c| 5 +
t;hbath...@linux.vnet.ibm.com>
Cc: Dave Hansen <dave.han...@intel.com>
Cc: Balbir Singh <bsinghar...@gmail.com>
Suggested-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/mmzone.h | 3 ++
=funcb%return
> perf probe -x ./bz5274 -a bz5274_funcc_return=funcc%return
> perf probe -x ./bz5274 -a bz5274_funcd_return=funcd%return
>
> perf record -e 'probe_bz5274:*' -aR ./bz5274
>
> Reported-by: Gustavo Luiz Duarte <gdua...@redhat.com>
> Reported-by: z...@red
> +static struct sched_domain_topology_level power9_topology[] = {
> +#ifdef CONFIG_SCHED_SMT
> + { cpu_smt_mask, powerpc_smt_flags, SD_INIT_NAME(SMT) },
> +#endif
> + { shared_cache_mask, powerpc_shared_cache_flags, SD_INIT_NAME(CACHE) },
> + { cpu_cpu_mask, SD_INIT_NAME(DIE) },
> +
* Peter Zijlstra [2018-08-08 09:58:41]:
> On Wed, Aug 08, 2018 at 12:39:31PM +0530, Srikar Dronamraju wrote:
> > With Commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> > sched domain") scheduler introduces an extra numa level. However that
>
is because
sched_domains_numa_level is now 2 on 2 node systems.
Fix this by allowing setting systems that have upto 2 numa levels as
NUMA_DIRECT.
While here remove a code that assumes level can be 0.
Fixes: 051f3ca02e46 "Introduce NUMA identity node sched domain"
Signed-off-by: Srikar Dronamraj
Carstens
Cc: Ingo Molnar
Cc: LKML
Fixes: 051f3ca02e46 "Introduce NUMA identity node sched domain"
Signed-off-by: Srikar Dronamraju
Signed-off-by: Srikar Dronamraju
---
include/linux/sched/topology.h | 6 ++
kernel/sched/sched.h | 4
2 files changed, 6 insertions(+
* Gautham R. Shenoy [2018-08-09 11:02:08]:
>
> 3) ppc64_cpu --smt=2
>SMT domain ceases to exist as each domain consists of just one
>group.
>
When seen in isolation, the above looks as if ppc64_cpu --smt=2 o/p says
" SMT domain ceases to exist"
> @@ -999,7 +1012,17 @@ static void
* Gautham R. Shenoy [2018-08-09 11:02:07]:
>
> int threads_per_core, threads_per_subcore, threads_shift;
> +bool has_big_cores;
> cpumask_t threads_core_mask;
> EXPORT_SYMBOL_GPL(threads_per_core);
> EXPORT_SYMBOL_GPL(threads_per_subcore);
> EXPORT_SYMBOL_GPL(threads_shift);
>
8-415,504-511
NUMA node9 CPU(s): 144-151,240-247,336-343,432-439
NUMA node10 CPU(s):152-159,248-255,344-351,440-447
NUMA node11 CPU(s):160-167,256-263,352-359,448-455
Previous attempt to solve this problem
https://patchwork.ozlabs.org/patch/530090/
Reported-by: Manjunatha H R
Signed-o
R
Signed-off-by: Srikar Dronamraju
---
arch/powerpc/include/asm/topology.h | 4
arch/powerpc/kernel/smp.c | 6 ++
arch/powerpc/mm/numa.c | 22 ++
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h
b
A node9 CPU(s): 144-151,240-247,336-343,432-439
NUMA node10 CPU(s):152-159,248-255,344-351,440-447
NUMA node11 CPU(s):160-167,256-263,352-359,448-455
Previous attempt to solve this problem
https://patchwork.ozlabs.org/patch/530090/
Reported-by: Manjunatha H R
Signed-off-by: Srik
8-415,504-511
NUMA node9 CPU(s): 144-151,240-247,336-343,432-439
NUMA node10 CPU(s):152-159,248-255,344-351,440-447
NUMA node11 CPU(s):160-167,256-263,352-359,448-455
Previous attempt to solve this problem
https://patchwork.ozlabs.org/patch/530090/
Reported-by: Manjunatha H R
Signed-o
* Michael Ellerman [2018-08-10 21:42:28]:
> Srikar Dronamraju writes:
> > diff --git a/arch/powerpc/include/asm/topology.h
> > b/arch/powerpc/include/asm/topology.h
> > index 16b077801a5f..70f2d2285ba7 100644
> > --- a/arch/powerpc/include/asm/topology.h
> &g
ling_mask to compare with the l2_cache_mask.
> This ensure that the CACHE level sched-domain is created, whose groups
> correspond to the threads of the big-core.
>
> With this patch, the SMT sched-domain with SMT=8,4,2 on big-core
> systems are as follows:
Reviewed-by: Srikar Dronamraju
;ibm,thread-groups" and a new structure to contain the parsed output.
>
> The patch also creates the sysfs file named "small_core_siblings" that
> returns the physical ids of the threads in the core that share the L1
> cache, translation cache and instruction data flow.
A node9 CPU(s): 144-151,240-247,336-343,432-439
NUMA node10 CPU(s):152-159,248-255,344-351,440-447
NUMA node11 CPU(s):160-167,256-263,352-359,448-455
Previous attempt to solve this problem
https://patchwork.ozlabs.org/patch/530090/
Reported-by: Manjunatha H R
Signed-off-by: Srik
A node9 CPU(s): 144-151,240-247,336-343,432-439
NUMA node10 CPU(s):152-159,248-255,344-351,440-447
NUMA node11 CPU(s):160-167,256-263,352-359,448-455
Previous attempt to solve this problem
https://patchwork.ozlabs.org/patch/530090/
Reported-by: Manjunatha H R
Signed-off-by: Srik
* Srikar Dronamraju [2018-08-10 22:30:18]:
> With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> sched domain") scheduler introduces an new numa level. However this
> leads to numa topology on 2 node systems no more marked as NUMA_DIRECT.
> Afte
* Michael Ellerman [2018-08-21 20:35:23]:
> On Fri, 2018-08-17 at 14:54:39 UTC, Srikar Dronamraju wrote:
> > On a shared lpar, Phyp will not update the cpu associativity at boot
> > time. Just after the boot system does recognize itself as a shared lpar and
> > trigger a re
* Peter Zijlstra [2018-08-31 12:41:15]:
> On Fri, Aug 31, 2018 at 03:22:48AM -0700, Srikar Dronamraju wrote:
>
> > At boot: Before topology update.
>
> How does that work; you do SMP bringup _before_ you know the topology !?
>
If you look at the other mail that I s
* Peter Zijlstra [2018-08-29 10:43:48]:
> On Fri, Aug 10, 2018 at 09:45:33AM -0700, Srikar Dronamraju wrote:
>
> >
> > CPU302 attaching NULL sched-domain.
> > CPU303 attaching NULL sched-domain.
> > BUG: arch topology borken
> > the DIE do
* Peter Zijlstra [2018-08-29 10:02:19]:
> On Fri, Aug 10, 2018 at 10:30:19PM +0530, Srikar Dronamraju wrote:
> > With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> > sched domain") scheduler introduces an new numa level. However on shared
> >
ping well with topology
updates. I know things weren't optimal after a topology change but they
worked. Now after 051f3ca02e46 "Introduce NUMA identity node sched
domain", systems stall. I am only exploring at ways to keep them working
as much as they were before that commit.
--
Thanks and Regards
Srikar Dronamraju
> +DECLARE_PER_CPU(cpumask_var_t, cpu_smallcore_map);
>
> +/*
> + * On big-cores system, cpu_l1_cache_map for each CPU corresponds to
> + * the set its siblings that share the L1-cache.
> + */
> +DEFINE_PER_CPU(cpumask_var_t, cpu_l1_cache_map);
>
Nit:
Can you add a comment on how
* Gautham R. Shenoy [2018-10-11 11:03:02]:
> From: "Gautham R. Shenoy"
>
>
> +#ifdef CONFIG_SCHED_SMT
> + if (has_big_cores) {
> + pr_info("Using small cores at SMT level\n");
> + power9_topology[0].mask = smallcore_smt_mask;
> +
Scheduler maintains sched_domains_numa_masks[], which is currently not
updated on cpu to node mapping changes. This can lead to machine
hangs or performance hit.
Fix numa_update_cpu_topology() to update sched_domains_numa_masks[].
Signed-off-by: Srikar Dronamraju
---
Changelog: v1->v2:
- Upda
) here?
> }
> }
>
--
Thanks and Regards
Srikar Dronamraju
* Srikar Dronamraju [2018-10-10 09:54:46]:
> Commit 2ea626306810 ("powerpc/topology: Get topology for shared
> processors at boot") will update the cpu node topology for shared lpars
> on PowerVM.
>
> However shared lpars on PowerVM also support VPHN and PRRN events.
&g
Scheduler maintains sched_domains_numa_masks[], which is currently not
updated on cpu to node mapping changes. This can lead to machine
regressions and performance regressions.
Fix numa_update_cpu_topology() to update sched_domains_numa_masks[].
Signed-off-by: Srikar Dronamraju
---
arch/powerpc
of fix, detect and skip early onlining of a offline node.
Fixes: 2ea626306810 ("powerpc/topology: Get topology for shared processors at
boot")
Reported-by: Pavithra Prakash
Signed-off-by: Srikar Dronamraju
---
arch/powerpc/mm/numa.c | 5 +++--
1 file changed, 3 insertions(+), 2 deleti
ode 3 size: 2044 MB
node 3 free: 2032 MB
node distances:
node 0 1 2 3
0: 10 40 40 40
1: 40 10 40 40
2: 40 40 10 40
3: 40 40 40 10
Fix this by skipping associativity lookup if the VPHN hcall failed.
Signed-off-by: Srikar Dronamraju
---
arch/powerpc/mm/numa.c | 4 ++
thing happen?
>
> If not; why not?
Yes distances can be 20, 40 or 80. There is nothing that makes the node
distance to be 40 always.
> So you're relying on sched_domain_numa_masks_set/clear() to fix this up,
> but that in turn relies on the sched_domain_numa_levels thing to stay
ints_depth is 2)
I am not sure if this will work if the node distance between the two nodes
happens to be 20.
> /*
> * Even though we connect cpus to numa domains later in SMP
> * init, we need to know the node ids now. This is because
>
--
Thanks and Regards
Srikar Dronamraju
if (update_cpu_associativity_changes_mask() > 0)
> - topology_schedule_update();
> + sdo = true;
> reset_topology_timer();
> }
> + if (sdo)
> + topology_schedule_update();
> + topology_scans++;
> }
Are the above two hunks necessary? Not getting how the current changes are
different from the previous.
--
Thanks and Regards
Srikar Dronamraju
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
L2 cache:512K
L3 cache:10240K
NUMA node0 CPU(s): 0-63
NUMA node1 CPU(s): 64-127
# cat /sys/devices/system/cpu/cpu0/topology/physical_package_id
-1
Signed-off-by: Srikar Dronamraju
---
arch/powerpc
d be triggered when the cpumasks are getting
updated. So I would expect this to continue working.
Or Am I missing someother migration related quirk?
> cheers
>
The other alternative that I see is
--
Thanks and Regards
Srikar Dronamraju
as Piggin
Cc: Abdul Haleem
Cc: Nathan Lynch
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Satheesh Rajendran
Srikar Dronamraju (3):
powerpc/vphn: Check for error from hcall_vphn
powerpc/numa: Early request for home node associativity
powerpc/numa: Remove late request for home node associativity
There is no point in unpacking associativity, if
H_HOME_NODE_ASSOCIATIVITY hcall has returned an error.
Also added error messages for H_PARAMETER and default case in
vphn_get_associativity.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Nathan Lynch
Cc
smp_setup_pacas before numa_setup_cpus.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Nathan Lynch
Cc: linuxppc-dev@lists.ozlabs.org
Reported-by: Satheesh Rajendran
Reported-by: Abdul Haleem
---
arch/powerpc/kernel/setup-common.c | 5 +++--
arch/powerpc/mm/numa.c
ativity.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Nathan Lynch
Cc: linuxppc-dev@lists.ozlabs.org
Reported-by: Satheesh Rajendran
Reported-by: Abdul Haleem
---
arch/powerpc/include/asm/topology.h | 4
arch/powerpc/kernel/smp.c | 5 -
ar
lscpu output is more in line with the system configuration.
Link to previous posting: https://patchwork.ozlabs.org/patch/1126145
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Vasant Hegde
Cc: Vaidyanathan Srinivasan
---
Changelog from v1:
In V1 cp
I'm going to quibble with this phrasing a bit. On SPLPAR the
> CPU nodes have no affinity information in the device tree at all. This
> comment implies that they may have incorrect information, which is
> AFAIK not the case.
>
Okay will clarify.
--
Thanks and Regards
Srikar Dronamraju
There is no value in unpacking associativity, if
H_HOME_NODE_ASSOCIATIVITY hcall has returned an error.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Nathan Lynch
Cc: linuxppc-dev@lists.ozlabs.org
Reported-by: Satheesh Rajendran
Reported-by: Abdul Haleem
Thanks for testing.
The fix for this patch series was to make sure per node workqueue possible
cpus is updated correctly at boot. However Node hotplug on KVM guests and
dlpar on PowerVM lpars aren't covered by this patch series. On systems that
support shared processor, the associativity of the poss
an
Cc: Nicholas Piggin
Cc: Abdul Haleem
Cc: Nathan Lynch
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Satheesh Rajendran
Srikar Dronamraju (4):
powerpc/vphn: Check for error from hcall_vphn
powerpc/numa: Handle extra hcall_vphn error cases
powerpc/numa: Early request for home node associativit
was not successful.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Nathan Lynch
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Satheesh Rajendran
Reported-by: Abdul Haleem
---
Changelog (v2->v1):
- Handled comments from Nathan Lynch
* Dont depend on pacas to be setup for the h
Currently code handles H_FUNCTION, H_SUCCESS, H_HARDWARE return codes.
However hcall_vphn can return other return codes. Now it also handles
H_PARAMETER return code. Also the rest return codes are handled under the
default case.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc
ativity.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Nathan Lynch
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Satheesh Rajendran
Reported-by: Abdul Haleem
---
arch/powerpc/include/asm/topology.h | 4
arch/powerpc/kernel/smp.c | 5 -
ar
the vphn
> call only once per cpu node, I think?
I didn't get "once per cpu node", How do we know which all cpus are part of
that cpu node? Or did you mean once per cpu core?
--
Thanks and Regards
Srikar Dronamraju
es in between.
> > If so, I think more care is needed. The algorithm should make the vphn
> > call only once per cpu node, I think?
>
> I didn't get "once per cpu node", How do we know which all cpus are part of
> that cpu node? Or did you mean once per cpu core?
--
Thanks and Regards
Srikar Dronamraju
Currently code handles H_FUNCTION, H_SUCCESS, H_HARDWARE return codes.
However hcall_vphn can return other return codes. Now it also handles
H_PARAMETER return code. Also the rest return codes are handled under the
default case.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc
1 - 100 of 571 matches
Mail list logo
