Re: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-03-19 Thread Joonsoo Kim
On Wed, Mar 18, 2015 at 03:33:02PM +0530, Aneesh Kumar K.V wrote:
> 
> >
> >  #ifdef CONFIG_CMA
> > +static void __init adjust_present_page_count(struct page *page, long count)
> > +{
> > +   struct zone *zone = page_zone(page);
> > +
> > +   zone->present_pages += count;
> > +}
> > +
> 
> May be adjust_page_zone_present_count() ?
> 

Hello,

This name is motivated from adjust_managed_page_count() which handles
zone's managed_page change.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-03-19 Thread Joonsoo Kim
On Wed, Mar 18, 2015 at 03:33:02PM +0530, Aneesh Kumar K.V wrote:
 
 
   #ifdef CONFIG_CMA
  +static void __init adjust_present_page_count(struct page *page, long count)
  +{
  +   struct zone *zone = page_zone(page);
  +
  +   zone-present_pages += count;
  +}
  +
 
 May be adjust_page_zone_present_count() ?
 

Hello,

This name is motivated from adjust_managed_page_count() which handles
zone's managed_page change.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-03-18 Thread Aneesh Kumar K.V

>
>  #ifdef CONFIG_CMA
> +static void __init adjust_present_page_count(struct page *page, long count)
> +{
> + struct zone *zone = page_zone(page);
> +
> + zone->present_pages += count;
> +}
> +

May be adjust_page_zone_present_count() ?


-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-03-18 Thread Aneesh Kumar K.V


  #ifdef CONFIG_CMA
 +static void __init adjust_present_page_count(struct page *page, long count)
 +{
 + struct zone *zone = page_zone(page);
 +
 + zone-present_pages += count;
 +}
 +

May be adjust_page_zone_present_count() ?


-aneesh

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-03-05 Thread Joonsoo Kim
On Tue, Mar 03, 2015 at 01:58:46PM +0530, Aneesh Kumar K.V wrote:
> Joonsoo Kim  writes:
> 
> > Until now, reserved pages for CMA are managed altogether with normal
> > page in the same zone. This approach has numorous problems and fixing
> > them isn't easy. To fix this situation, ZONE_CMA is introduced in
> > previous patch, but, not yet populated. This patch implement population
> > of ZONE_CMA by stealing reserved pages from normal zones. This stealing
> > break one uncertain assumption on zone, that is, zone isn't overlapped.
> > In the early of this series, some check is inserted to every zone's span
> > iterator to handle zone overlap so there would be no problem with
> > this assumption break.
> >
> > To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because
> > these pages are only applicable for movable type and ZONE_CMA could
> > contain highmem.
> >
> > Implementation itself is very easy to understand. Do steal when cma
> > area is initialized and recalculate values for per zone data structure.
> >
> > Signed-off-by: Joonsoo Kim 
> > ---
> >  include/linux/gfp.h |   10 --
> >  include/linux/mm.h  |1 +
> >  mm/cma.c|   23 ---
> >  mm/page_alloc.c |   42 +++---
> >  4 files changed, 64 insertions(+), 12 deletions(-)
> >
> > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > index 619eb20..d125440 100644
> > --- a/include/linux/gfp.h
> > +++ b/include/linux/gfp.h
> > @@ -186,6 +186,12 @@ static inline int gfpflags_to_migratetype(const gfp_t 
> > gfp_flags)
> >  #define OPT_ZONE_DMA32 ZONE_NORMAL
> >  #endif
> >  
> > +#ifdef CONFIG_CMA
> > +#define OPT_ZONE_CMA ZONE_CMA
> > +#else
> > +#define OPT_ZONE_CMA ZONE_MOVABLE
> > +#endif
> > +
> 
> Does that mean with CONFIG_CMA we always try ZONE_CMA first and then
> fallback to ZONE_MOVABLE ? If so won't we hit termporary CMA allocation
> failures that can result with pinned movable pages ?

Hello, Aneesh.

IIUC, Johannes's fair allocation policy patchset makes us uses
individual zones fairly. So, before freepage on ZONE_CMA is exhausted,
ZONE_MOVABLE will be used. :)

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-03-05 Thread Joonsoo Kim
On Tue, Mar 03, 2015 at 01:58:46PM +0530, Aneesh Kumar K.V wrote:
 Joonsoo Kim iamjoonsoo@lge.com writes:
 
  Until now, reserved pages for CMA are managed altogether with normal
  page in the same zone. This approach has numorous problems and fixing
  them isn't easy. To fix this situation, ZONE_CMA is introduced in
  previous patch, but, not yet populated. This patch implement population
  of ZONE_CMA by stealing reserved pages from normal zones. This stealing
  break one uncertain assumption on zone, that is, zone isn't overlapped.
  In the early of this series, some check is inserted to every zone's span
  iterator to handle zone overlap so there would be no problem with
  this assumption break.
 
  To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because
  these pages are only applicable for movable type and ZONE_CMA could
  contain highmem.
 
  Implementation itself is very easy to understand. Do steal when cma
  area is initialized and recalculate values for per zone data structure.
 
  Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
  ---
   include/linux/gfp.h |   10 --
   include/linux/mm.h  |1 +
   mm/cma.c|   23 ---
   mm/page_alloc.c |   42 +++---
   4 files changed, 64 insertions(+), 12 deletions(-)
 
  diff --git a/include/linux/gfp.h b/include/linux/gfp.h
  index 619eb20..d125440 100644
  --- a/include/linux/gfp.h
  +++ b/include/linux/gfp.h
  @@ -186,6 +186,12 @@ static inline int gfpflags_to_migratetype(const gfp_t 
  gfp_flags)
   #define OPT_ZONE_DMA32 ZONE_NORMAL
   #endif
   
  +#ifdef CONFIG_CMA
  +#define OPT_ZONE_CMA ZONE_CMA
  +#else
  +#define OPT_ZONE_CMA ZONE_MOVABLE
  +#endif
  +
 
 Does that mean with CONFIG_CMA we always try ZONE_CMA first and then
 fallback to ZONE_MOVABLE ? If so won't we hit termporary CMA allocation
 failures that can result with pinned movable pages ?

Hello, Aneesh.

IIUC, Johannes's fair allocation policy patchset makes us uses
individual zones fairly. So, before freepage on ZONE_CMA is exhausted,
ZONE_MOVABLE will be used. :)

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-03-03 Thread Aneesh Kumar K.V
Joonsoo Kim  writes:

> Until now, reserved pages for CMA are managed altogether with normal
> page in the same zone. This approach has numorous problems and fixing
> them isn't easy. To fix this situation, ZONE_CMA is introduced in
> previous patch, but, not yet populated. This patch implement population
> of ZONE_CMA by stealing reserved pages from normal zones. This stealing
> break one uncertain assumption on zone, that is, zone isn't overlapped.
> In the early of this series, some check is inserted to every zone's span
> iterator to handle zone overlap so there would be no problem with
> this assumption break.
>
> To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because
> these pages are only applicable for movable type and ZONE_CMA could
> contain highmem.
>
> Implementation itself is very easy to understand. Do steal when cma
> area is initialized and recalculate values for per zone data structure.
>
> Signed-off-by: Joonsoo Kim 
> ---
>  include/linux/gfp.h |   10 --
>  include/linux/mm.h  |1 +
>  mm/cma.c|   23 ---
>  mm/page_alloc.c |   42 +++---
>  4 files changed, 64 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 619eb20..d125440 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -186,6 +186,12 @@ static inline int gfpflags_to_migratetype(const gfp_t 
> gfp_flags)
>  #define OPT_ZONE_DMA32 ZONE_NORMAL
>  #endif
>  
> +#ifdef CONFIG_CMA
> +#define OPT_ZONE_CMA ZONE_CMA
> +#else
> +#define OPT_ZONE_CMA ZONE_MOVABLE
> +#endif
> +

Does that mean with CONFIG_CMA we always try ZONE_CMA first and then
fallback to ZONE_MOVABLE ? If so won't we hit termporary CMA allocation
failures that can result with pinned movable pages ?

-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-03-03 Thread Aneesh Kumar K.V
Joonsoo Kim iamjoonsoo@lge.com writes:

 Until now, reserved pages for CMA are managed altogether with normal
 page in the same zone. This approach has numorous problems and fixing
 them isn't easy. To fix this situation, ZONE_CMA is introduced in
 previous patch, but, not yet populated. This patch implement population
 of ZONE_CMA by stealing reserved pages from normal zones. This stealing
 break one uncertain assumption on zone, that is, zone isn't overlapped.
 In the early of this series, some check is inserted to every zone's span
 iterator to handle zone overlap so there would be no problem with
 this assumption break.

 To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because
 these pages are only applicable for movable type and ZONE_CMA could
 contain highmem.

 Implementation itself is very easy to understand. Do steal when cma
 area is initialized and recalculate values for per zone data structure.

 Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
 ---
  include/linux/gfp.h |   10 --
  include/linux/mm.h  |1 +
  mm/cma.c|   23 ---
  mm/page_alloc.c |   42 +++---
  4 files changed, 64 insertions(+), 12 deletions(-)

 diff --git a/include/linux/gfp.h b/include/linux/gfp.h
 index 619eb20..d125440 100644
 --- a/include/linux/gfp.h
 +++ b/include/linux/gfp.h
 @@ -186,6 +186,12 @@ static inline int gfpflags_to_migratetype(const gfp_t 
 gfp_flags)
  #define OPT_ZONE_DMA32 ZONE_NORMAL
  #endif
  
 +#ifdef CONFIG_CMA
 +#define OPT_ZONE_CMA ZONE_CMA
 +#else
 +#define OPT_ZONE_CMA ZONE_MOVABLE
 +#endif
 +

Does that mean with CONFIG_CMA we always try ZONE_CMA first and then
fallback to ZONE_MOVABLE ? If so won't we hit termporary CMA allocation
failures that can result with pinned movable pages ?

-aneesh

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-02-16 Thread Joonsoo Kim
On Sat, Feb 14, 2015 at 02:02:16PM +0900, Gioh Kim wrote:
> 
> 
> 2015-02-12 오후 4:32에 Joonsoo Kim 이(가) 쓴 글:
> > Until now, reserved pages for CMA are managed altogether with normal
> > page in the same zone. This approach has numorous problems and fixing
> > them isn't easy. To fix this situation, ZONE_CMA is introduced in
> > previous patch, but, not yet populated. This patch implement population
> > of ZONE_CMA by stealing reserved pages from normal zones. This stealing
> > break one uncertain assumption on zone, that is, zone isn't overlapped.
> > In the early of this series, some check is inserted to every zone's span
> > iterator to handle zone overlap so there would be no problem with
> > this assumption break.
> > 
> > To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because
> 
> I think it might be typo of GFP_HIGHUSER_MOVABLE.
> 

Yes, I will correct next time.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-02-16 Thread Joonsoo Kim
On Sat, Feb 14, 2015 at 02:02:16PM +0900, Gioh Kim wrote:
 
 
 2015-02-12 오후 4:32에 Joonsoo Kim 이(가) 쓴 글:
  Until now, reserved pages for CMA are managed altogether with normal
  page in the same zone. This approach has numorous problems and fixing
  them isn't easy. To fix this situation, ZONE_CMA is introduced in
  previous patch, but, not yet populated. This patch implement population
  of ZONE_CMA by stealing reserved pages from normal zones. This stealing
  break one uncertain assumption on zone, that is, zone isn't overlapped.
  In the early of this series, some check is inserted to every zone's span
  iterator to handle zone overlap so there would be no problem with
  this assumption break.
  
  To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because
 
 I think it might be typo of GFP_HIGHUSER_MOVABLE.
 

Yes, I will correct next time.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-02-13 Thread Gioh Kim


2015-02-12 오후 4:32에 Joonsoo Kim 이(가) 쓴 글:
> Until now, reserved pages for CMA are managed altogether with normal
> page in the same zone. This approach has numorous problems and fixing
> them isn't easy. To fix this situation, ZONE_CMA is introduced in
> previous patch, but, not yet populated. This patch implement population
> of ZONE_CMA by stealing reserved pages from normal zones. This stealing
> break one uncertain assumption on zone, that is, zone isn't overlapped.
> In the early of this series, some check is inserted to every zone's span
> iterator to handle zone overlap so there would be no problem with
> this assumption break.
> 
> To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because

I think it might be typo of GFP_HIGHUSER_MOVABLE.

> these pages are only applicable for movable type and ZONE_CMA could
> contain highmem.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-02-13 Thread Gioh Kim


2015-02-12 오후 4:32에 Joonsoo Kim 이(가) 쓴 글:
 Until now, reserved pages for CMA are managed altogether with normal
 page in the same zone. This approach has numorous problems and fixing
 them isn't easy. To fix this situation, ZONE_CMA is introduced in
 previous patch, but, not yet populated. This patch implement population
 of ZONE_CMA by stealing reserved pages from normal zones. This stealing
 break one uncertain assumption on zone, that is, zone isn't overlapped.
 In the early of this series, some check is inserted to every zone's span
 iterator to handle zone overlap so there would be no problem with
 this assumption break.
 
 To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because

I think it might be typo of GFP_HIGHUSER_MOVABLE.

 these pages are only applicable for movable type and ZONE_CMA could
 contain highmem.
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/