Displaying 20 results from an estimated 30 matches for "alloc_pages_vma".
2019 Jun 20
2
[PATCH 05/22] mm: export alloc_pages_vma
...ff-by: Christoph Hellwig <hch at lst.de>
> ---
> mm/mempolicy.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 01600d80ae01..f9023b5fba37 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -2098,6 +2098,7 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
> out:
> return page;
> }
> +EXPORT_SYMBOL_GPL(alloc_pages_vma);
All allocator exported symbols are EXPORT_SYMBOL, what is a reason to
have this one special?
--
Michal Hocko
SUSE Labs
2019 Jun 13
0
[PATCH 05/22] mm: export alloc_pages_vma
...he real thing later in this series.
Signed-off-by: Christoph Hellwig <hch at lst.de>
---
mm/mempolicy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 01600d80ae01..f9023b5fba37 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2098,6 +2098,7 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
out:
return page;
}
+EXPORT_SYMBOL_GPL(alloc_pages_vma);
/**
* alloc_pages_current - Allocate pages.
--
2.20.1
2019 Jun 14
1
[PATCH 05/22] mm: export alloc_pages_vma
...rd at nvidia.com>
thanks,
--
John Hubbard
NVIDIA
> mm/mempolicy.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 01600d80ae01..f9023b5fba37 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -2098,6 +2098,7 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
> out:
> return page;
> }
> +EXPORT_SYMBOL_GPL(alloc_pages_vma);
>
> /**
> * alloc_pages_current - Allocate pages.
>
2019 Jun 24
0
[PATCH 05/22] mm: export alloc_pages_vma
...t;
> > ---
> > mm/mempolicy.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> > index 01600d80ae01..f9023b5fba37 100644
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -2098,6 +2098,7 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
> > out:
> > return page;
> > }
> > +EXPORT_SYMBOL_GPL(alloc_pages_vma);
>
> All allocator exported symbols are EXPORT_SYMBOL, what is a reason to
> have this one special?
I asked for this simply because it...
2019 Jun 26
0
[PATCH 06/25] mm: export alloc_pages_vma
...toph Hellwig <hch at lst.de>
Reviewed-by: John Hubbard <jhubbard at nvidia.com>
---
mm/mempolicy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 01600d80ae01..f48569aa1863 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2098,6 +2098,7 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
out:
return page;
}
+EXPORT_SYMBOL(alloc_pages_vma);
/**
* alloc_pages_current - Allocate pages.
--
2.20.1
2019 Jun 25
0
[PATCH 05/22] mm: export alloc_pages_vma
On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> > I asked for this simply because it was not exported historically. In
> > general I want to establish explicit export-type criteria so the
> > community can spend less time debating when to use EXPORT_SYMBOL_GPL
> > [1].
> >
> > The thought
2019 Jun 26
0
[PATCH 05/22] mm: export alloc_pages_vma
On Tue 25-06-19 12:52:18, Dan Williams wrote:
[...]
> > Documentation/process/stable-api-nonsense.rst
>
> That document has failed to preclude symbol export fights in the past
> and there is a reasonable argument to try not to retract functionality
> that had been previously exported regardless of that document.
Can you point me to any specific example where this would be the
2019 Jun 26
1
[PATCH 05/22] mm: export alloc_pages_vma
On Tue, Jun 25, 2019 at 10:46 PM Michal Hocko <mhocko at kernel.org> wrote:
>
> On Tue 25-06-19 12:52:18, Dan Williams wrote:
> [...]
> > > Documentation/process/stable-api-nonsense.rst
> >
> > That document has failed to preclude symbol export fights in the past
> > and there is a reasonable argument to try not to retract functionality
> > that had
2020 Jun 22
1
[PATCH 14/16] mm/thp: add THP allocation helper
...mm/huge_memory.c | 16 ++++++++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 67a0774e080b..1c7d968a27d3 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -562,6 +562,16 @@ extern struct page *alloc_pages_vma(gfp_t gfp_mask, int order,
> alloc_pages_vma(gfp_mask, 0, vma, addr, numa_node_id(), false)
> #define alloc_page_vma_node(gfp_mask, vma, addr, node) \
> alloc_pages_vma(gfp_mask, 0, vma, addr, node, false)
> +#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
> +extern struct page *alloc_...
2019 Jun 25
0
[PATCH 05/22] mm: export alloc_pages_vma
On Tue 25-06-19 11:03:53, Dan Williams wrote:
> On Tue, Jun 25, 2019 at 8:01 AM Michal Hocko <mhocko at kernel.org> wrote:
> >
> > On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> > > On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> > > > I asked for this simply because it was not exported historically. In
> > > > general I
2019 Jun 25
2
[PATCH 05/22] mm: export alloc_pages_vma
On Tue, Jun 25, 2019 at 12:01 PM Michal Hocko <mhocko at kernel.org> wrote:
>
> On Tue 25-06-19 11:03:53, Dan Williams wrote:
> > On Tue, Jun 25, 2019 at 8:01 AM Michal Hocko <mhocko at kernel.org> wrote:
> > >
> > > On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> > > > On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
>
2019 Jun 25
2
[PATCH 05/22] mm: export alloc_pages_vma
On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> I asked for this simply because it was not exported historically. In
> general I want to establish explicit export-type criteria so the
> community can spend less time debating when to use EXPORT_SYMBOL_GPL
> [1].
>
> The thought in this instance is that it is not historically exported
> to modules and it is
2020 Jun 19
0
[PATCH 14/16] mm/thp: add THP allocation helper
...lude/linux/gfp.h | 10 ++++++++++
mm/huge_memory.c | 16 ++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 67a0774e080b..1c7d968a27d3 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -562,6 +562,16 @@ extern struct page *alloc_pages_vma(gfp_t gfp_mask, int order,
alloc_pages_vma(gfp_mask, 0, vma, addr, numa_node_id(), false)
#define alloc_page_vma_node(gfp_mask, vma, addr, node) \
alloc_pages_vma(gfp_mask, 0, vma, addr, node, false)
+#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
+extern struct page *alloc_transhugepage(struct vm_a...
2019 Jun 25
2
[PATCH 05/22] mm: export alloc_pages_vma
On Tue, Jun 25, 2019 at 8:01 AM Michal Hocko <mhocko at kernel.org> wrote:
>
> On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> > On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> > > I asked for this simply because it was not exported historically. In
> > > general I want to establish explicit export-type criteria so the
> > >
2020 Nov 06
0
[PATCH v3 4/6] mm/thp: add THP allocation helper
...gfp.h
index c603237e006c..242398c4b556 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -564,6 +564,16 @@ static inline struct page *alloc_pages(gfp_t gfp_mask, unsigned int order)
#define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0)
#define alloc_page_vma(gfp_mask, vma, addr) \
alloc_pages_vma(gfp_mask, 0, vma, addr, numa_node_id(), false)
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+extern struct page *alloc_transhugepage(struct vm_area_struct *vma,
+ unsigned long addr);
+#else
+static inline struct page *alloc_transhugepage(struct vm_area_struct *vma,
+ unsigned long addr)
+{
+ retur...
2019 Jul 12
2
Out of memory: kill process
...2303.508371] oom_kill_process+0x272/0x280
[762303.508372] ? oom_badness+0x23/0x130
[762303.508374] out_of_memory+0x10c/0x480
[762303.508377] __alloc_pages_slowpath+0x9d8/0xdb0
[762303.508380] ? blk_mq_make_request+0x28a/0x530
[762303.508382] __alloc_pages_nodemask+0x258/0x2a0
[762303.508386] alloc_pages_vma+0x7c/0x1d0
[762303.508390] __read_swap_cache_async+0x147/0x200
[762303.508392] read_swap_cache_async+0x28/0x60
[762303.508394] swap_cluster_readahead+0x217/0x290
[762303.508397] ? __switch_to_asm+0x40/0x70
[762303.508399] ? __switch_to+0x115/0x450
[762303.508401] ? swap_range_free+0xa3/0xc0
[...
2014 Feb 03
3
Memory leak - how to investigate
...capable_noaudit+0x3c/0x70
[<ffffffff8111d2c2>] ? oom_kill_process+0x82/0x2a0
[<ffffffff8111d201>] ? select_bad_process+0xe1/0x120
[<ffffffff8111d700>] ? out_of_memory+0x220/0x3c0
[<ffffffff8112c3dc>] ? __alloc_pages_nodemask+0x8ac/0x8d0
[<ffffffff81160d6a>] ? alloc_pages_vma+0x9a/0x150
[<ffffffff81143f0b>] ? handle_pte_fault+0x76b/0xb50
[<ffffffffa00c60f9>] ? ext4_check_acl+0x29/0x90 [ext4]
[<ffffffff81075887>] ? current_fs_time+0x27/0x30
[<ffffffff8114452a>] ? handle_mm_fault+0x23a/0x310
[<ffffffff810474e9>] ? __do_page_fault+0x...
2018 Jul 17
2
Samba 4.8.3 out of memory error
...kernel: [<ffffffff81134ef0>] ? out_of_memory+0x220/0x3c0
Jul 16 14:14:36 soda kernel: [<ffffffff811418e1>] ?
__alloc_pages_nodemask+0x941/0x960
Jul 16 14:14:36 soda kernel: [<ffffffff81060d0c>] ? __wake_up_common+0x5c/0x90
Jul 16 14:14:36 soda kernel: [<ffffffff8117aefa>] ? alloc_pages_vma+0x9a/0x150
Jul 16 14:14:36 soda kernel: [<ffffffff8116e2b2>] ?
read_swap_cache_async+0xf2/0x160
Jul 16 14:14:36 soda kernel: [<ffffffff8116ee09>] ? valid_swaphandles+0x69/0x160
Jul 16 14:14:36 soda kernel: [<ffffffff8116e3a7>] ? swapin_readahead+0x87/0xc0
Jul 16 14:14:36 soda kern...
2019 Jul 12
0
Out of memory: kill process
...+0x272/0x280
> [762303.508372] ? oom_badness+0x23/0x130
> [762303.508374] out_of_memory+0x10c/0x480
> [762303.508377] __alloc_pages_slowpath+0x9d8/0xdb0
> [762303.508380] ? blk_mq_make_request+0x28a/0x530
> [762303.508382] __alloc_pages_nodemask+0x258/0x2a0
> [762303.508386] alloc_pages_vma+0x7c/0x1d0
> [762303.508390] __read_swap_cache_async+0x147/0x200
> [762303.508392] read_swap_cache_async+0x28/0x60
> [762303.508394] swap_cluster_readahead+0x217/0x290
> [762303.508397] ? __switch_to_asm+0x40/0x70
> [762303.508399] ? __switch_to+0x115/0x450
> [762303.508401]...
2020 Jun 19
22
[PATCH 00/16] mm/hmm/nouveau: THP mapping and migration
These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go
into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM
self tests. Patch 7-8 prepare nouveau for the meat of this series which
adds support and testing for compound page mapping of system memory
(patches 9-11) and compound page migration to device private memory
(patches 12-16). Since these changes are split