Re: [PATCH] mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED

a44737...@suse.cz/ > [2] https://lwn.net/Articles/932201/ > > Signed-off-by: Vlastimil Babka Acked-by: David Rientjes The Kconfig option says that SLAB will be removed in a few cycles. I think we should wait until at least the next LTS kernel is forked at the end of the year so that use

Re: [PATCH] mm: Remove HARDENED_USERCOPY_FALLBACK

153 > Signed-off-by: Stephen Kitt > Suggested-by: Kees Cook Acked-by: David Rientjes

Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

> >> arch/s390/Kconfig | 1 + > > > > You forgot to delete __HAVE_ARCH_PTE_SPECIAL from > > arch/riscv/include/asm/pgtable-bits.h > > Damned ! > Thanks for catching it. > Squashing the two patches together at least allowed it to be caught easil

Re: [PATCH v9 21/24] perf tools: Add support for the SPF perf event

On Mon, 26 Mar 2018, Andi Kleen wrote: > > Aside: should there be a new spec_flt field for struct task_struct that > > complements maj_flt and min_flt and be exported through /proc/pid/stat? > > No. task_struct is already too bloated. If you need per process tracking > you can always get it

Re: [PATCH 2/3] mm: replace __HAVE_ARCH_PTE_SPECIAL

On Mon, 9 Apr 2018, Christoph Hellwig wrote: > > -#ifdef __HAVE_ARCH_PTE_SPECIAL > > +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL > > # define HAVE_PTE_SPECIAL 1 > > #else > > # define HAVE_PTE_SPECIAL 0 > > I'd say kill this odd indirection and just use the > CONFIG_ARCH_HAS_PTE_SPECIAL symbol

Re: [mm] b1f0502d04: INFO:trying_to_register_non-static_key

On Wed, 4 Apr 2018, Laurent Dufour wrote: > > I also think the following is needed: > > > > diff --git a/fs/exec.c b/fs/exec.c > > --- a/fs/exec.c > > +++ b/fs/exec.c > > @@ -312,6 +312,10 @@ static int __bprm_mm_init(struct linux_binprm *bprm) > > vma->vm_flags = VM_SOFTDIRTY |

Re: [mm] b1f0502d04: INFO:trying_to_register_non-static_key

On Tue, 3 Apr 2018, David Rientjes wrote: > > >> I found the root cause of this lockdep warning. > > >> > > >> In mmap_region(), unmap_region() may be called while vma_link() has not > > >> been > > >> called. This happens during

Re: [mm] b1f0502d04: INFO:trying_to_register_non-static_key

On Wed, 28 Mar 2018, Laurent Dufour wrote: > On 26/03/2018 00:10, David Rientjes wrote: > > On Wed, 21 Mar 2018, Laurent Dufour wrote: > > > >> I found the root cause of this lockdep warning. > >> > >> In mmap_region(), unmap_region() may be called while

Re: [PATCH v9 04/24] mm: Prepare for FAULT_FLAG_SPECULATIVE

On Wed, 28 Mar 2018, Laurent Dufour wrote: > >> diff --git a/include/linux/mm.h b/include/linux/mm.h > >> index 4d02524a7998..2f3e98edc94a 100644 > >> --- a/include/linux/mm.h > >> +++ b/include/linux/mm.h > >> @@ -300,6 +300,7 @@ extern pgprot_t protection_map[16]; > >> #define FAULT_FLAG_USER

Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()

On Tue, 3 Apr 2018, Jerome Glisse wrote: > > When dealing with the speculative fault path we should use the VMA's field > > cached value stored in the vm_fault structure. > > > > Currently vm_normal_page() is using the pointer to the VMA to fetch the > > vm_flags value. This patch provides a new

Re: [PATCH v9 06/24] mm: make pte_unmap_same compatible with SPF

On Tue, 3 Apr 2018, Jerome Glisse wrote: > > diff --git a/mm/memory.c b/mm/memory.c > > index 21b1212a0892..4bc7b0bdcb40 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -2309,21 +2309,29 @@ static bool pte_map_lock(struct vm_fault *vmf) > > * parts, do_swap_page must check under lock

Re: [PATCH v9 17/24] mm: Protect mm_rb tree with a rwlock

On Tue, 13 Mar 2018, Laurent Dufour wrote: > This change is inspired by the Peter's proposal patch [1] which was > protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in > that particular case, and it is introducing major performance degradation > due to excessive scheduling

Re: [PATCH v9 16/24] mm: Introduce __page_add_new_anon_rmap()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > When dealing with speculative page fault handler, we may race with VMA > being split or merged. In this case the vma->vm_start and vm->vm_end > fields may not match the address the page fault is occurring. > > This can only happens when the VMA is

Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index a84ddc218bbd..73b8b99f482b 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1263,8 +1263,11 @@ struct zap_details { > pgoff_t last_index; /*

Re: [PATCH v9 14/24] mm: Introduce __maybe_mkwrite()

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index dfa81a638b7c..a84ddc218bbd 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -684,13 +684,18 @@ void free_compound_page(struct page *page); > * pte_mkwrite. But

Re: [PATCH v9 13/24] mm: Introduce __lru_cache_add_active_or_unevictable

() which has the vma flags > value parameter instead of the vma pointer. > > Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> Acked-by: David Rientjes <rient...@google.com>

Re: [PATCH v9 12/24] mm/migrate: Pass vm_fault pointer to migrate_misplaced_page()

> could be used. > > Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> Acked-by: David Rientjes <rient...@google.com>

Re: [PATCH v9 11/24] mm: Cache some VMA fields in the vm_fault structure

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index ef6ef0627090..dfa81a638b7c 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -359,6 +359,12 @@ struct vm_fault { >* page table to avoid

Re: [PATCH v9 09/24] mm: protect mremap() against SPF hanlder

On Wed, 28 Mar 2018, Laurent Dufour wrote: > >> @@ -326,7 +336,10 @@ static unsigned long move_vma(struct vm_area_struct > >> *vma, > >>mremap_userfaultfd_prep(new_vma, uf); > >>arch_remap(mm, old_addr, old_addr + old_len, > >> new_addr, new_addr +

Re: [PATCH v9 01/24] mm: Introduce CONFIG_SPECULATIVE_PAGE_FAULT

On Wed, 28 Mar 2018, Laurent Dufour wrote: > > Putting this in mm/Kconfig is definitely the right way to go about it > > instead of any generic option in arch/*. > > > > My question, though, was making this configurable by the user: > > > > config SPECULATIVE_PAGE_FAULT > > bool

Re: [PATCH v9 06/24] mm: make pte_unmap_same compatible with SPF

On Wed, 28 Mar 2018, Laurent Dufour wrote: > >> @@ -2913,7 +2921,8 @@ int do_swap_page(struct vm_fault *vmf) > >>int exclusive = 0; > >>int ret = 0; > > > > Initialization is now unneeded. > > I'm sorry, what "initialization" are you talking about here ? > The initialization of the

Re: [PATCH v9 01/24] mm: Introduce CONFIG_SPECULATIVE_PAGE_FAULT

On Wed, 28 Mar 2018, Laurent Dufour wrote: > >> This configuration variable will be used to build the code needed to > >> handle speculative page fault. > >> > >> By default it is turned off, and activated depending on architecture > >> support. > >> > >> Suggested-by: Thomas Gleixner

Re: [PATCH v9 09/24] mm: protect mremap() against SPF hanlder

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 88042d843668..ef6ef0627090 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2189,16 +2189,24 @@ void anon_vma_interval_tree_verify(struct > anon_vma_chain *node); > extern

Re: [PATCH v9 08/24] mm: Protect VMA modifications using VMA sequence count

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/mm/mmap.c b/mm/mmap.c > index 5898255d0aeb..d6533cb85213 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -847,17 +847,18 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned > long start, > } > > if (start !=

Re: [PATCH v9 08/24] mm: Protect VMA modifications using VMA sequence count

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 65ae54659833..a2d9c87b7b0b 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -1136,8 +1136,11 @@ static ssize_t clear_refs_write(struct file *file, > const char __user *buf,

Re: [PATCH v9 07/24] mm: VMA sequence count

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/mm/mmap.c b/mm/mmap.c > index faf85699f1a1..5898255d0aeb 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -558,6 +558,10 @@ void __vma_link_rb(struct mm_struct *mm, struct > vm_area_struct *vma, > else >

Re: [PATCH v9 06/24] mm: make pte_unmap_same compatible with SPF

ned long va, struct vm_area_struct *vma) > @@ -2913,7 +2921,8 @@ int do_swap_page(struct vm_fault *vmf) > int exclusive = 0; > int ret = 0; Initialization is now unneeded. Otherwise: Acked-by: David Rientjes <rient...@google.com>

Re: [PATCH v9 21/24] perf tools: Add support for the SPF perf event

On Tue, 13 Mar 2018, Laurent Dufour wrote: > Add support for the new speculative faults event. > > Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> Acked-by: David Rientjes <rient...@google.com> Aside: should there be a new spec_flt field for struct task_str

Re: [PATCH v9 20/24] perf: Add a speculative page fault sw event

On Tue, 13 Mar 2018, Laurent Dufour wrote: > Add a new software event to count succeeded speculative page faults. > > Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com> Acked-by: David Rientjes <rient...@google.com>

Re: [PATCH v9 23/24] x86/mm: Add speculative pagefault handling

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c > index e6af2b464c3d..a73cf227edd6 100644 > --- a/arch/x86/mm/fault.c > +++ b/arch/x86/mm/fault.c > @@ -1239,6 +1239,9 @@ __do_page_fault(struct pt_regs *regs, unsigned long > error_code, >

Re: [PATCH v9 24/24] powerpc/mm: Add speculative page fault

On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c > index 866446cf2d9a..104f3cc86b51 100644 > --- a/arch/powerpc/mm/fault.c > +++ b/arch/powerpc/mm/fault.c > @@ -392,6 +392,9 @@ static int __do_page_fault(struct pt_regs *regs, unsigned >

Re: [mm] b1f0502d04: INFO:trying_to_register_non-static_key

On Wed, 21 Mar 2018, Laurent Dufour wrote: > I found the root cause of this lockdep warning. > > In mmap_region(), unmap_region() may be called while vma_link() has not been > called. This happens during the error path if call_mmap() failed. > > The only to fix that particular case is to call >

Re: [PATCH v9 05/24] mm: Introduce pte_spinlock for FAULT_FLAG_SPECULATIVE

On Tue, 13 Mar 2018, Laurent Dufour wrote: > When handling page fault without holding the mmap_sem the fetch of the > pte lock pointer and the locking will have to be done while ensuring > that the VMA is not touched in our back. > > So move the fetch and locking operations in a dedicated

Re: [PATCH v9 04/24] mm: Prepare for FAULT_FLAG_SPECULATIVE

On Tue, 13 Mar 2018, Laurent Dufour wrote: > From: Peter Zijlstra > > When speculating faults (without holding mmap_sem) we need to validate > that the vma against which we loaded pages is still valid when we're > ready to install the new PTE. > > Therefore, replace the

Re: [PATCH v9 01/24] mm: Introduce CONFIG_SPECULATIVE_PAGE_FAULT

On Tue, 13 Mar 2018, Laurent Dufour wrote: > This configuration variable will be used to build the code needed to > handle speculative page fault. > > By default it is turned off, and activated depending on architecture > support. > > Suggested-by: Thomas Gleixner >

Re: [PATCH 1/9] mm/huge_memory: Use zap_deposited_table() more

thers to use the helper to clean things up a bit. > > Cc: "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> > Cc: "Kirill A. Shutemov" <kirill.shute...@linux.intel.com> > Cc: linux...@kvack.org > Signed-off-by: Oliver O'Halloran <ooh...@gmail.com> Acked-by: David Rientjes <rient...@google.com>

[no subject]

--- Begin Message --- On Thu, 28 Jan 2016, David Rientjes wrote: > On Thu, 28 Jan 2016, Christian Borntraeger wrote: > > > Indeed, I only touched the identity mapping and dump stack. > > The question is do we really want to change free_init_pages as well? > > The unmappi

[no subject]

--- Begin Message --- On Thu, 28 Jan 2016, Christian Borntraeger wrote: > Indeed, I only touched the identity mapping and dump stack. > The question is do we really want to change free_init_pages as well? > The unmapping during runtime causes significant overhead, but the > unmapping after init

[no subject]

--- Begin Message --- On Wed, 27 Jan 2016, Christian Borntraeger wrote: > We can use debug_pagealloc_enabled() to check if we can map > the identity mapping with 2MB pages. We can also add the state > into the dump_stack output. > > The patch does not touch the code for the 1GB pages, which

[no subject]

aeger <borntrae...@de.ibm.com> > Reviewed-by: Heiko Carstens <heiko.carst...@de.ibm.com> Acked-by: David Rientjes <rient...@google.com> --- End Message --- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node

On Thu, 30 Jul 2015, Vlastimil Babka wrote: diff --git a/mm/huge_memory.c b/mm/huge_memory.c index aa58a32..56355f2 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2469,7 +2469,7 @@ khugepaged_alloc_page(struct page **hpage, gfp_t gfp, struct mm_struct *mm, */

Re: [PATCH] mm: rename and document alloc_pages_exact_node

On Thu, 23 Jul 2015, Christoph Lameter wrote: The only possible downside would be existing users of alloc_pages_node() that are calling it with an offline node. Since it's a VM_BUG_ON() that would catch that, I think it should be changed to a VM_WARN_ON() and eventually fixed up because

Re: [PATCH] mm: rename and document alloc_pages_exact_node

On Wed, 22 Jul 2015, Paolo Bonzini wrote: diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 2d73807..a8723a8 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -3158,7 +3158,7 @@ static struct vmcs *alloc_vmcs_cpu(int cpu) struct page *pages; struct vmcs

Re: [PATCH] mm: rename and document alloc_pages_exact_node

On Wed, 22 Jul 2015, Vlastimil Babka wrote: alloc_pages_exact_node(), as you said, connotates that the allocation will take place on that node or will fail. So why not go beyond this patch and actually make alloc_pages_exact_node() set __GFP_THISNODE and then call into a new

Re: [PATCH] mm: rename and document alloc_pages_exact_node

On Tue, 21 Jul 2015, Vlastimil Babka wrote: The function alloc_pages_exact_node() was introduced in 6484eb3e2a81 (page allocator: do not check NUMA node ID when the caller knows the node is valid) as an optimized variant of alloc_pages_node(), that doesn't allow the node id to be -1.

Re: [RFC PATCH 1/2] powerpc/numa: fix cpu_to_node() usage during boot

On Fri, 10 Jul 2015, Nishanth Aravamudan wrote: After the percpu areas on initialized and cpu_to_node() is correct, it would be really nice to be able to make numa_cpu_lookup_table[] be __initdata since it shouldn't be necessary anymore. That probably has cpu callbacks that need to be

Re: [RFC PATCH 1/2] powerpc/numa: fix cpu_to_node() usage during boot

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 returned by those calls now depend on the per-cpu area being setup, but that is not guaranteed

Re: [RFC,1/2] powerpc/numa: fix cpu_to_node() usage during boot

On Wed, 8 Jul 2015, Nishanth Aravamudan wrote: It looks like the symptom is that the per-cpu areas are all allocated on node 0, is that all that goes wrong? Yes, that's the symptom. I cc'd a few folks to see if they could help indicate the performance implications of such a setup --

Re: [RFC PATCH 2/2] powerpc/smp: use early_cpu_to_node() instead of direct references to numa_cpu_lookup_table

On Thu, 2 Jul 2015, Nishanth Aravamudan wrote: 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 n...@linux.vnet.ibm.com When early_cpu_to_node() is __init: Acked-by: David Rientjes rient

Re: [RFC PATCH] powerpc/numa: reset node_possible_map to only node_online_map

On Thu, 5 Mar 2015, Nishanth Aravamudan wrote: diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c index 0257a7d659ef..24de29b3651b 100644 --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -958,9 +958,17 @@ void __init initmem_init(void) memblock_dump_all();

Re: [RFC PATCH] powerpc/numa: reset node_possible_map to only node_online_map

On Thu, 5 Mar 2015, Nishanth Aravamudan wrote: So if we compare to x86: arch/x86/mm/numa.c::numa_init(): nodes_clear(numa_nodes_parsed); nodes_clear(node_possible_map); nodes_clear(node_online_map); ... numa_register_memblks(...);

Re: [RFC PATCH] powerpc/numa: reset node_possible_map to only node_online_map

On Fri, 6 Mar 2015, Michael Ellerman wrote: diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c index 0257a7d659ef..24de29b3651b 100644 --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -958,9 +958,17 @@ void __init initmem_init(void)

Re: [PATCH v2] slab: Fix nodeid bounds check for non-contiguous node IDs

that. Signed-off-by: Paul Mackerras pau...@samba.org Acked-by: David Rientjes rient...@google.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node

On Tue, 22 Jul 2014, Nishanth Aravamudan wrote: I think there's two use cases of interest: - allocating from a memoryless node where numa_node_id() is memoryless, and - using node_to_mem_node() for a possibly-memoryless node for kmalloc(). I believe the first should have

Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node

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't seem like it can just node_distance() solely, right? Because that just tells us the relative cost

Re: [PATCH] powerpc: Fix build warning

by a function returning 'const int', which doesn't make sense to gcc. Drop 'const' to fix the problem. Reported-by: Vincent Guittot vincent.guit...@linaro.org Signed-off-by: Guenter Roeck li...@roeck-us.net Acked-by: David Rientjes rient...@google.com Although it's strange you report

Re: NUMA topology question wrt. d4edc5b6

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/powerpc/include/asm/topology.h @@ -18,6 +18,7 @@ struct device_node; */

Re: Node 0 not necessary for powerpc?

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 several bugs lately where Node 0 is online, but has no CPUs and no memory on it, on powerpc.

Re: [RESEND PATCH] slub: search partial list on numa_mem_id(), instead of numa_node_id()

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. Acked-by: Nishanth Aravamudan n...@linux.vnet.ibm.com Acked-by: David Rientjes rient...@google.com Acked

Re: Node 0 not necessary for powerpc?

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, which has no cpus and no memory (and no PCI devices): numactl --hardware available: 4 nodes (0-3) node 0 cpus: node 0 size: 0 MB node 0 free: 0 MB node 1

[patch] mm, hotplug: avoid compiling memory hotremove functions when disabled

, including x86). remove_memory_block() becomes static since it is not referenced outside of drivers/base/memory.c. Build tested on x86 and powerpc with CONFIG_MEMORY_HOTREMOVE both enabled and disabled. Signed-off-by: David Rientjes rient...@google.com --- arch/powerpc/platforms/pseries/hotplug

[patch 4/4] mm, oom: remove statically defined arch functions of same name

: H. Peter Anvin h...@zytor.com Cc: Thomas Gleixner t...@linutronix.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Paul Mundt let...@linux-sh.org Signed-off-by: David Rientjes rient...@google.com --- arch/powerpc/mm/fault.c | 27

Re: [RFC PATCH 1/12] memory-hotplug : rename remove_memory to offline_memory

On Wed, 27 Jun 2012, Yasuaki Ishimatsu wrote: remove_memory() does not remove memory but just offlines memory. The patch changes name of it to offline_memory(). The kernel is never going to physically remove the memory itself, so I don't see the big problem with calling it remove_memory().

Re: [RFC PATCH 2/12] memory-hogplug : check memory offline in offline_pages

On Wed, 27 Jun 2012, Yasuaki Ishimatsu wrote: Index: linux-3.5-rc4/mm/memory_hotplug.c === --- linux-3.5-rc4.orig/mm/memory_hotplug.c2012-06-26 13:28:16.743211538 +0900 +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-06-26

[patch] sched, numa: Allocate node_queue on any node for offline nodes

struct node_queue must be allocated with NUMA_NO_NODE for nodes that are not (yet) online, otherwise the page allocator has a bad zonelist and results in an early crash. Tested-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: David Rientjes rient...@google.com --- kernel/sched/numa.c

Re: linux-next: PowerPC boot failures in next-20120521

on any node for offline nodes struct node_queue must be allocated with NUMA_NO_NODE for nodes that are not (yet) online, otherwise the page allocator has a bad zonelist. Signed-off-by: David Rientjes rient...@google.com --- diff --git a/kernel/sched/numa.c b/kernel/sched/numa.c --- a/kernel/sched

Re: linux-next: PowerPC boot failures in next-20120521

On Tue, 22 May 2012, Michael Neuling wrote: console [tty0] enabled console [hvc0] enabled pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes) Mount-cache hash table entries:

Re: linux-next: PowerPC boot failures in next-20120521

On Tue, 22 May 2012, Michael Neuling wrote: Trying David's patch just posted doesn't fix it. Hmm, what does CONFIG_DEBUG_VM say? No set. Sorry, should have read Not set I mean if it's set, what does it emit to the kernel log with my patch applied? I made

Re: linux-next: PowerPC boot failures in next-20120521

On Tue, 22 May 2012, Michael Neuling wrote: Sorry, got it... CONFIG_DEBUG_VM enabled below... pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes) Mount-cache hash table

[patch] powerpc, mm: fix section mismatch for mark_reserved_regions_for_nid

do_init_bootmem(), which is in .init.text, so it must be in the same section to avoid a section mismatch warning. Reported-by: Subrata Modak subr...@linux.vnet.ibm.com Signed-off-by: David Rientjes rient...@google.com --- arch/powerpc/mm/numa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions

[patch] powerpc, mm: fix section mismatch for read_n_cells

read_n_cells() cannot be marked as .devinit.text since it is referenced from two functions that are not in that section: of_get_lmb_size() and hot_add_drconf_scn_to_nid(). Signed-off-by: David Rientjes rient...@google.com --- arch/powerpc/mm/numa.c |2 +- 1 files changed, 1 insertions

Re: Badness with the kernel version 2.6.35-rc1-git1 running on P6 box

On Fri, 16 Jul 2010, Dave Hansen wrote: SLUB: Unable to allocate memory on node -1 (gfp=0x20) cache: kmalloc-16384, object size: 16384, buffer size: 16384, default order: 2, min order: 0 node 0: slabs: 28, objs: 292, free: 0 ip: page allocation failure. order:0, mode:0x8020

Re: [patch 11/14] powerpc: invoke oom-killer from page fault

On Fri, 23 Apr 2010, npig...@suse.de wrote: As explained in commit 1c0fe6e3bd, we want to call the architecture independent oom killer when getting an unexplained OOM from handle_mm_fault, rather than simply killing current. Cc: linuxppc-...@ozlabs.org Cc: Benjamin Herrenschmidt

Re: [PATCH] Fix fake numa on ppc

On Wed, 2 Sep 2009, Ankita Garg wrote: With the patch, # cat /proc/cmdline root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G # cat /sys/devices/system/node/node0/cpulist 0-3 # cat /sys/devices/system/node/node1/cpulist Oh! interesting.. cpuless nodes :) I think

Re: [PATCH] Fix fake numa on ppc

On Wed, 2 Sep 2009, Benjamin Herrenschmidt wrote: Since I'm pretty sure there could be CPU less nodes just like there could be memory-less nodes, it would be good if fake numa could simulate them too :-) You don't want to simulate cpu less nodes since they do have affinity to ranges of

Re: [PATCH v2] Fix fake numa on ppc

On Wed, 2 Sep 2009, Ankita Garg wrote: Hi, Below is a patch to fix a couple of issues with fake numa node creation on ppc: 1) Presently, fake nodes could be created such that real numa node boundaries are not respected. So a node could have lmbs that belong to different real nodes.

Re: [PATCH v2] Fix fake numa on ppc

On Wed, 2 Sep 2009, Ankita Garg wrote: Currently, the behavior of fake numa is not so on x86 as well? Below is a sample output from a single node x86 system booted with numa=fake=8: # cat node0/cpulist # cat node1/cpulist ... # cat node6/cpulist # cat node7/cpulist 0-7

Re: [PATCH v2] Fix fake numa on ppc

On Thu, 3 Sep 2009, Balbir Singh wrote: Right, I'm proposing an alternate mapping scheme (which we've used for years) for both platforms such that a cpu is bound (and is set in cpumask_of_node()) to each fake node with which it has physical affinity. That is the only way for zonelist

Re: [PATCH] Fake NUMA emulation for PowerPC

On Sat, 8 Dec 2007, Balbir Singh wrote: You're going to want to distribute the cpu's based on how they match up physically with the actual platform that you're running on. x86_64 does Could you explain this better, how does it match up CPU's with fake NUMA memory? Is there some

Re: [PATCH] Fake NUMA emulation for PowerPC

On Sat, 8 Dec 2007, Balbir Singh wrote: Yes, they all appear on node 0. We could have tweaks to distribute CPU's as well. You're going to want to distribute the cpu's based on how they match up physically with the actual platform that you're running on. x86_64 does this already and it

Re: [PATCH] Fake NUMA emulation for PowerPC

On Sat, 8 Dec 2007, Balbir Singh wrote: To be able to test the memory controller under NUMA, I use fake NUMA nodes. x86-64 has a similar feature, the code I have here is the simplest I could come up with for PowerPC. Magnus Damm had patches from over a year ago that, I believe, made much of

Re: [PATCH] Fake NUMA emulation for PowerPC

On Fri, 7 Dec 2007, Olof Johansson wrote: Comments are as always welcome! Care to explain what this is useful for? (Not saying it's a stupid idea, just wondering what the reason for doing it is). Fake NUMA has always been useful for testing NUMA code without having to have a wide range