Subject: [PATCH] mm: use vm_map_ram for only temporal object

Subject: [PATCH] mm: use vm_map_ram for only temporal object

[Gioh Kim]

The vm_map_ram has fragment problem because it couldn't
purge a chunk(ie, 4M address space) if there is a pinning object in
that addresss space. So it could consume all VMALLOC address space
easily.
We can fix the fragmentation problem with using vmap instead of vm_map_ram
but vmap is known to slow operation compared to vm_map_ram. Minchan said
vm_map_ram is 5 times faster than vmap in his experiment. So I thought
we should fix fragment problem of vm_map_ram because our proprietary
GPU driver has used it heavily.

On second thought, it's not an easy because we should reuse freed
space for solving the problem and it could make more IPI and bitmap operation
for searching hole. It could mitigate API's goal which is very fast mapping.
And even fragmentation problem wouldn't show in 64 bit machine.

Another option is that the user should separate long-life and short-life
object and use vmap for long-life but vm_map_ram for short-life.
If we inform the user about the characteristic of vm_map_ram
the user can choose one according to the page lifetime.

Let's add some notice messages to user.

Signed-off-by: Gioh Kim <gioh.kim@lge.com>
Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
---
 mm/vmalloc.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0fdf968..85b6687 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1083,6 +1083,12 @@ EXPORT_SYMBOL(vm_unmap_ram);
  * @node: prefer to allocate data structures on this node
  * @prot: memory protection to use. PAGE_KERNEL for regular RAM
  *
+ * If you use this function for below VMAP_MAX_ALLOC pages, it could be faster
+ * than vmap so it's good. But if you mix long-life and short-life object
+ * with vm_map_ram, it could consume lots of address space by fragmentation
+ * (expecially, 32bit machine). You could see failure in the end.
+ * Please use this function for short-life object.
+ *
  * Returns: a pointer to the address that has been mapped, or %NULL on failure
  */
 void *vm_map_ram(struct page **pages, unsigned int count, int node, pgprot_t prot)
--
1.7.9.5

Subject: [PATCH] mm: use vm_map_ram for only temporal object

[Gioh Kim]

The vm_map_ram has fragment problem because it couldn't
purge a chunk(ie, 4M address space) if there is a pinning object in
that addresss space. So it could consume all VMALLOC address space
easily.
We can fix the fragmentation problem with using vmap instead of vm_map_ram
but vmap is known to slow operation compared to vm_map_ram. Minchan said
vm_map_ram is 5 times faster than vmap in his experiment. So I thought
we should fix fragment problem of vm_map_ram because our proprietary
GPU driver has used it heavily.

On second thought, it's not an easy because we should reuse freed
space for solving the problem and it could make more IPI and bitmap operation
for searching hole. It could mitigate API's goal which is very fast mapping.
And even fragmentation problem wouldn't show in 64 bit machine.

Another option is that the user should separate long-life and short-life
object and use vmap for long-life but vm_map_ram for short-life.
If we inform the user about the characteristic of vm_map_ram
the user can choose one according to the page lifetime.

Let's add some notice messages to user.

Signed-off-by: Gioh Kim <gioh.kim@lge.com>
Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
---
 mm/vmalloc.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0fdf968..85b6687 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1083,6 +1083,12 @@ EXPORT_SYMBOL(vm_unmap_ram);
  * @node: prefer to allocate data structures on this node
  * @prot: memory protection to use. PAGE_KERNEL for regular RAM
  *
+ * If you use this function for below VMAP_MAX_ALLOC pages, it could be faster
+ * than vmap so it's good. But if you mix long-life and short-life object
+ * with vm_map_ram, it could consume lots of address space by fragmentation
+ * (expecially, 32bit machine). You could see failure in the end.
+ * Please use this function for short-life object.
+ *
  * Returns: a pointer to the address that has been mapped, or %NULL on failure
  */
 void *vm_map_ram(struct page **pages, unsigned int count, int node, pgprot_t prot)
--
1.7.9.5


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Subject: [PATCH] mm: use vm_map_ram for only temporal object

[SeongJae Park]

Hello Gioh,

On Mon, Mar 10, 2014 at 7:16 PM, Gioh Kim <gioh.kim@lge.com> wrote:
>
> The vm_map_ram has fragment problem because it couldn't
> purge a chunk(ie, 4M address space) if there is a pinning object in
> that addresss space. So it could consume all VMALLOC address space
> easily.
> We can fix the fragmentation problem with using vmap instead of vm_map_ram
> but vmap is known to slow operation compared to vm_map_ram. Minchan said
> vm_map_ram is 5 times faster than vmap in his experiment. So I thought
> we should fix fragment problem of vm_map_ram because our proprietary
> GPU driver has used it heavily.
>
> On second thought, it's not an easy because we should reuse freed
> space for solving the problem and it could make more IPI and bitmap operation
> for searching hole. It could mitigate API's goal which is very fast mapping.
> And even fragmentation problem wouldn't show in 64 bit machine.
>
> Another option is that the user should separate long-life and short-life
> object and use vmap for long-life but vm_map_ram for short-life.
> If we inform the user about the characteristic of vm_map_ram
> the user can choose one according to the page lifetime.
>
> Let's add some notice messages to user.
>
> Signed-off-by: Gioh Kim <gioh.kim@lge.com>
> Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
> ---
>  mm/vmalloc.c |    6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 0fdf968..85b6687 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1083,6 +1083,12 @@ EXPORT_SYMBOL(vm_unmap_ram);
>   * @node: prefer to allocate data structures on this node
>   * @prot: memory protection to use. PAGE_KERNEL for regular RAM
>   *
> + * If you use this function for below VMAP_MAX_ALLOC pages, it could be faster
> + * than vmap so it's good. But if you mix long-life and short-life object
> + * with vm_map_ram, it could consume lots of address space by fragmentation
> + * (expecially, 32bit machine). You could see failure in the end.

looks like trivial typo. Shouldn't s/expecially/especially/ ?

Thanks.

> + * Please use this function for short-life object.
> + *
>   * Returns: a pointer to the address that has been mapped, or %NULL on failure
>   */
>  void *vm_map_ram(struct page **pages, unsigned int count, int node, pgprot_t prot)
> --
> 1.7.9.5
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a hrefmailto:"dont@kvack.org"> email@kvack.org </a>

Re: Subject: [PATCH] mm: use vm_map_ram for only temporal object

[SeongJae Park]

Hello Gioh,

On Mon, Mar 10, 2014 at 7:16 PM, Gioh Kim <gioh.kim@lge.com> wrote:
>
> The vm_map_ram has fragment problem because it couldn't
> purge a chunk(ie, 4M address space) if there is a pinning object in
> that addresss space. So it could consume all VMALLOC address space
> easily.
> We can fix the fragmentation problem with using vmap instead of vm_map_ram
> but vmap is known to slow operation compared to vm_map_ram. Minchan said
> vm_map_ram is 5 times faster than vmap in his experiment. So I thought
> we should fix fragment problem of vm_map_ram because our proprietary
> GPU driver has used it heavily.
>
> On second thought, it's not an easy because we should reuse freed
> space for solving the problem and it could make more IPI and bitmap operation
> for searching hole. It could mitigate API's goal which is very fast mapping.
> And even fragmentation problem wouldn't show in 64 bit machine.
>
> Another option is that the user should separate long-life and short-life
> object and use vmap for long-life but vm_map_ram for short-life.
> If we inform the user about the characteristic of vm_map_ram
> the user can choose one according to the page lifetime.
>
> Let's add some notice messages to user.
>
> Signed-off-by: Gioh Kim <gioh.kim@lge.com>
> Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
> ---
>  mm/vmalloc.c |    6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 0fdf968..85b6687 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1083,6 +1083,12 @@ EXPORT_SYMBOL(vm_unmap_ram);
>   * @node: prefer to allocate data structures on this node
>   * @prot: memory protection to use. PAGE_KERNEL for regular RAM
>   *
> + * If you use this function for below VMAP_MAX_ALLOC pages, it could be faster
> + * than vmap so it's good. But if you mix long-life and short-life object
> + * with vm_map_ram, it could consume lots of address space by fragmentation
> + * (expecially, 32bit machine). You could see failure in the end.

looks like trivial typo. Shouldn't s/expecially/especially/ ?

Thanks.

> + * Please use this function for short-life object.
> + *
>   * Returns: a pointer to the address that has been mapped, or %NULL on failure
>   */
>  void *vm_map_ram(struct page **pages, unsigned int count, int node, pgprot_t prot)
> --
> 1.7.9.5
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a hrefmailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: Subject: [PATCH] mm: use vm_map_ram for only temporal object

[Gioh Kim]

Hello,

I got a mail from Andrew Morton that
he fixed my typo and poor English 
like this: http://ozlabs.org/~akpm/mmots/broken-out/mm-vmallocc-enhance-vm_map_ram-comment-fix.patch

Thank you for your attention.



> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of SeongJae Park
> Sent: Tuesday, March 11, 2014 8:51 PM
> To: Gioh Kim
> Cc: Zhang Yanfei; Minchan Kim; Andrew Morton; Joonsoo Kim; linux-
> mm@kvack.org; linux-kernel@vger.kernel.org; 이건호; chanho.min@lge.com;
> Johannes Weiner
> Subject: Re: Subject: [PATCH] mm: use vm_map_ram for only temporal object
> 
> Hello Gioh,
> 
> On Mon, Mar 10, 2014 at 7:16 PM, Gioh Kim <gioh.kim@lge.com> wrote:
> >
> > The vm_map_ram has fragment problem because it couldn't purge a
> > chunk(ie, 4M address space) if there is a pinning object in that
> > addresss space. So it could consume all VMALLOC address space easily.
> > We can fix the fragmentation problem with using vmap instead of
> > vm_map_ram but vmap is known to slow operation compared to vm_map_ram.
> > Minchan said vm_map_ram is 5 times faster than vmap in his experiment.
> > So I thought we should fix fragment problem of vm_map_ram because our
> > proprietary GPU driver has used it heavily.
> >
> > On second thought, it's not an easy because we should reuse freed
> > space for solving the problem and it could make more IPI and bitmap
> > operation for searching hole. It could mitigate API's goal which is very
> fast mapping.
> > And even fragmentation problem wouldn't show in 64 bit machine.
> >
> > Another option is that the user should separate long-life and
> > short-life object and use vmap for long-life but vm_map_ram for short-
> life.
> > If we inform the user about the characteristic of vm_map_ram the user
> > can choose one according to the page lifetime.
> >
> > Let's add some notice messages to user.
> >
> > Signed-off-by: Gioh Kim <gioh.kim@lge.com>
> > Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
> > ---
> >  mm/vmalloc.c |    6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 0fdf968..85b6687 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -1083,6 +1083,12 @@ EXPORT_SYMBOL(vm_unmap_ram);
> >   * @node: prefer to allocate data structures on this node
> >   * @prot: memory protection to use. PAGE_KERNEL for regular RAM
> >   *
> > + * If you use this function for below VMAP_MAX_ALLOC pages, it could
> > + be faster
> > + * than vmap so it's good. But if you mix long-life and short-life
> > + object
> > + * with vm_map_ram, it could consume lots of address space by
> > + fragmentation
> > + * (expecially, 32bit machine). You could see failure in the end.
> 
> looks like trivial typo. Shouldn't s/expecially/especially/ ?
> 
> Thanks.
> 
> > + * Please use this function for short-life object.
> > + *
> >   * Returns: a pointer to the address that has been mapped, or %NULL on
> failure
> >   */
> >  void *vm_map_ram(struct page **pages, unsigned int count, int node,
> > pgprot_t prot)
> > --
> > 1.7.9.5
> >
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in the body
> > to majordomo@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a hrefmailto:"dont@kvack.org"> email@kvack.org </a>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

RE: Subject: [PATCH] mm: use vm_map_ram for only temporal object

[Gioh Kim]

Hello,

I got a mail from Andrew Morton that
he fixed my typo and poor English 
like this: http://ozlabs.org/~akpm/mmots/broken-out/mm-vmallocc-enhance-vm_map_ram-comment-fix.patch

Thank you for your attention.



> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of SeongJae Park
> Sent: Tuesday, March 11, 2014 8:51 PM
> To: Gioh Kim
> Cc: Zhang Yanfei; Minchan Kim; Andrew Morton; Joonsoo Kim; linux-
> mm@kvack.org; linux-kernel@vger.kernel.org; 이건호; chanho.min@lge.com;
> Johannes Weiner
> Subject: Re: Subject: [PATCH] mm: use vm_map_ram for only temporal object
> 
> Hello Gioh,
> 
> On Mon, Mar 10, 2014 at 7:16 PM, Gioh Kim <gioh.kim@lge.com> wrote:
> >
> > The vm_map_ram has fragment problem because it couldn't purge a
> > chunk(ie, 4M address space) if there is a pinning object in that
> > addresss space. So it could consume all VMALLOC address space easily.
> > We can fix the fragmentation problem with using vmap instead of
> > vm_map_ram but vmap is known to slow operation compared to vm_map_ram.
> > Minchan said vm_map_ram is 5 times faster than vmap in his experiment.
> > So I thought we should fix fragment problem of vm_map_ram because our
> > proprietary GPU driver has used it heavily.
> >
> > On second thought, it's not an easy because we should reuse freed
> > space for solving the problem and it could make more IPI and bitmap
> > operation for searching hole. It could mitigate API's goal which is very
> fast mapping.
> > And even fragmentation problem wouldn't show in 64 bit machine.
> >
> > Another option is that the user should separate long-life and
> > short-life object and use vmap for long-life but vm_map_ram for short-
> life.
> > If we inform the user about the characteristic of vm_map_ram the user
> > can choose one according to the page lifetime.
> >
> > Let's add some notice messages to user.
> >
> > Signed-off-by: Gioh Kim <gioh.kim@lge.com>
> > Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
> > ---
> >  mm/vmalloc.c |    6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 0fdf968..85b6687 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -1083,6 +1083,12 @@ EXPORT_SYMBOL(vm_unmap_ram);
> >   * @node: prefer to allocate data structures on this node
> >   * @prot: memory protection to use. PAGE_KERNEL for regular RAM
> >   *
> > + * If you use this function for below VMAP_MAX_ALLOC pages, it could
> > + be faster
> > + * than vmap so it's good. But if you mix long-life and short-life
> > + object
> > + * with vm_map_ram, it could consume lots of address space by
> > + fragmentation
> > + * (expecially, 32bit machine). You could see failure in the end.
> 
> looks like trivial typo. Shouldn't s/expecially/especially/ ?
> 
> Thanks.
> 
> > + * Please use this function for short-life object.
> > + *
> >   * Returns: a pointer to the address that has been mapped, or %NULL on
> failure
> >   */
> >  void *vm_map_ram(struct page **pages, unsigned int count, int node,
> > pgprot_t prot)
> > --
> > 1.7.9.5
> >
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in the body
> > to majordomo@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a hrefmailto:"dont@kvack.org"> email@kvack.org </a>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>