ng dereferenced is
> of size MAX_NUMNODES. If the nodeid is in range but invalid (for
> example if the node is off-line), the BUG_ON in the next line will
> catch that.
>
> Signed-off-by: Paul Mackerras
Acked-by: David Rientjes
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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 guarant
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 set
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
When early_cpu_to_node() is __init:
Acked-by: Da
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 nee
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. Unf
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;
> > s
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 alloc
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 b
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,
>*/
>
werpc, 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
---
arch/powerpc/platforms/pseries/hotplug-memory.c
e 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.
>
> Acked-by: Nishanth Aravamudan
> Acked-by: David R
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;
>
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.
^
>
> This is caused by a function returning 'const int', which doesn't
> make sense to gcc. Drop 'const' to fix the problem.
>
> Reported-by: Vincent Guittot
> Signed-off-by: Guenter Roeck
Acked-by: David Rientjes
Although it's strange you
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
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 fir
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
> no
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(
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)
> > >
> > >
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(...);
>
> arch/x
ese five can easily be solved with the
following.
powerpc, mm: fix section mismatch for mark_reserved_regions_for_nid
mark_reserved_regions_for_nid() is only called from 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 Mo
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
---
arch/powerpc/mm/numa.c |2 +-
1 files changed, 1 insertions(+), 1 deletions
Anvin"
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Paul Mundt
Signed-off-by: David Rientjes
---
arch/powerpc/mm/fault.c | 27 ---
arch/sh/mm/fault.c | 19 +++
arch/x86/mm/fault.c | 23 --
On Sat, 24 Mar 2012, Peter Zijlstra wrote:
> Yeah, so Nacked-by: Peter Zijlstra
>
> Also, why didn't lockdep catch it?
>
> Fix sparse already instead of smearing ugly all over.
>
Fully agreed, please don't add this to the oom killer.
___
Linuxppc-de
a memory hotplug notifier or it needs to pass
NUMA_NO_NODE for nodes that aren't online. Until we get the former, the
following should fix it.
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) o
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 entri
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?
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
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
Signed-off-by: David Rientjes
---
kernel/sched/numa.c |3 ++-
1 files changed, 2
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()
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 1
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
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
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 node
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
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 zoneli
e mask argument is either
> NODE_MASK_ALL or node_online_map) just use the first_online_node
> macro and remove the any_online_node macro since there are no users.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Andrew Morton
> Cc: David Rientjes
> Cc: KAMEZAWA Hiroyuki
> Cc: M
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
>
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, m
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
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 s
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 m
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
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 r
sues/153
> Signed-off-by: Stephen Kitt
> Suggested-by: Kees Cook
Acked-by: David Rientjes
others to use the helper to clean things up a bit.
>
> Cc: "Aneesh Kumar K.V"
> Cc: "Kirill A. Shutemov"
> Cc: linux...@kvack.org
> Signed-off-by: Oliver O'Halloran
Acked-by: David Rientjes
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
> Signed-off-by: Laurent Dufou
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 pte_offset_map_lock() ca
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 functio
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
>
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
> l
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,
>
On Tue, 13 Mar 2018, Laurent Dufour wrote:
> Add a new software event to count succeeded speculative page faults.
>
> Signed-off-by: Laurent Dufour
Acked-by: David Rientjes
On Tue, 13 Mar 2018, Laurent Dufour wrote:
> Add support for the new speculative faults event.
>
> Signed-off-by: Laurent Dufour
Acked-by: David Rientjes
Aside: should there be a new spec_flt field for struct task_struct that
complements maj_flt and min_flt and be exported through
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
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
> mm->highest_vm_e
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,
>
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 != vma->vm_star
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
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
> >> Signed
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 ret
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 "Speculativ
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 + ne
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
lags
> could be used.
>
> Signed-off-by: Laurent Dufour
Acked-by: David Rientjes
hich has the vma flags
> value parameter instead of the vma pointer.
>
> Signed-off-by: Laurent Dufour
Acked-by: David Rientjes
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 get_user_pag
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; /* Highest
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 spli
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 ope
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 b
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
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
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
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 the
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 | VM_STACK_FLAG
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 directl
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 thr
> >> 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
--- 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 ignor
Reviewed-by: Heiko Carstens
Acked-by: David Rientjes
--- End Message ---
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--- 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 im
--- 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
84 matches
Mail list logo
