Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

On Wed, Sep 21, 2016 at 08:17:27PM +0530, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V"  writes:
> 
> > Joonsoo Kim  writes:
> >
> >> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
> >>> Joonsoo Kim  writes:
> >>> 
> >>> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
> >>> > :
> >>> >> js1...@gmail.com writes:
> >>> >>
> >>> >>> From: Joonsoo Kim 
> >>> >>>
> >>> >>> Hello,
> >>> >>>
> >>> >>> Changes from v4
> >>> >>> o Rebase on next-20160825
> >>> >>> o Add general fix patch for lowmem reserve
> >>> >>> o Fix lowmem reserve ratio
> >>> >>> o Fix zone span optimizaion per Vlastimil
> >>> >>> o Fix pageset initialization
> >>> >>> o Change invocation timing on cma_init_reserved_areas()
> >>> >>
> >>> >> I don't see much information regarding how we interleave between
> >>> >> ZONE_CMA and other zones for movable allocation. Is that explained in
> >>> >> any of the patch ? The fair zone allocator got removed by
> >>> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
> >>> >
> >>> > Interleaving would not work since the fair zone allocator policy is 
> >>> > removed.
> >>> > I don't think that it's a big problem because it is just matter of
> >>> > timing to fill
> >>> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
> >>> > any case.
> >>> 
> >>> Does that mean a CMA allocation will now be slower because in most case we
> >>> will need to reclaim ? The zone list will now have ZONE_CMA in the
> >>> beginning right ?
> >>
> >> ZONE_CMA will be used first but I don't think that CMA allocation will
> >> be slower. In most case, memory would be fully used (usually
> >> by page cache). So, we need reclaim or migration in any case.
> >
> > Considering that the upstream kernel doesn't allow migration of THP
> > pages, this would mean that migrate will fail in most case if we have
> > THP enabled and the THP allocation request got satisfied via ZONE_CMA.
> > Isn't that going to be a problem ?
> >
> 
> Even though we have the issues of migration failures due to pinned and
> THP pages in ZONE_CMA, overall the code is simpler. IMHO we should get
> this upstream now and work on solving those issues later.

Yep! I will take a look on those problems after merging this patchset.

> 
> You can add for the complete series.
> 
> Reviewed-by: Aneesh Kumar K.V 

Thanks!

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

On Wed, Sep 21, 2016 at 08:17:27PM +0530, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V"  writes:
> 
> > Joonsoo Kim  writes:
> >
> >> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
> >>> Joonsoo Kim  writes:
> >>> 
> >>> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
> >>> > :
> >>> >> js1...@gmail.com writes:
> >>> >>
> >>> >>> From: Joonsoo Kim 
> >>> >>>
> >>> >>> Hello,
> >>> >>>
> >>> >>> Changes from v4
> >>> >>> o Rebase on next-20160825
> >>> >>> o Add general fix patch for lowmem reserve
> >>> >>> o Fix lowmem reserve ratio
> >>> >>> o Fix zone span optimizaion per Vlastimil
> >>> >>> o Fix pageset initialization
> >>> >>> o Change invocation timing on cma_init_reserved_areas()
> >>> >>
> >>> >> I don't see much information regarding how we interleave between
> >>> >> ZONE_CMA and other zones for movable allocation. Is that explained in
> >>> >> any of the patch ? The fair zone allocator got removed by
> >>> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
> >>> >
> >>> > Interleaving would not work since the fair zone allocator policy is 
> >>> > removed.
> >>> > I don't think that it's a big problem because it is just matter of
> >>> > timing to fill
> >>> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
> >>> > any case.
> >>> 
> >>> Does that mean a CMA allocation will now be slower because in most case we
> >>> will need to reclaim ? The zone list will now have ZONE_CMA in the
> >>> beginning right ?
> >>
> >> ZONE_CMA will be used first but I don't think that CMA allocation will
> >> be slower. In most case, memory would be fully used (usually
> >> by page cache). So, we need reclaim or migration in any case.
> >
> > Considering that the upstream kernel doesn't allow migration of THP
> > pages, this would mean that migrate will fail in most case if we have
> > THP enabled and the THP allocation request got satisfied via ZONE_CMA.
> > Isn't that going to be a problem ?
> >
> 
> Even though we have the issues of migration failures due to pinned and
> THP pages in ZONE_CMA, overall the code is simpler. IMHO we should get
> this upstream now and work on solving those issues later.

Yep! I will take a look on those problems after merging this patchset.

> 
> You can add for the complete series.
> 
> Reviewed-by: Aneesh Kumar K.V 

Thanks!

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Aneesh Kumar K.V]

"Aneesh Kumar K.V"  writes:

> Joonsoo Kim  writes:
>
>> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
>>> Joonsoo Kim  writes:
>>> 
>>> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
>>> > :
>>> >> js1...@gmail.com writes:
>>> >>
>>> >>> From: Joonsoo Kim 
>>> >>>
>>> >>> Hello,
>>> >>>
>>> >>> Changes from v4
>>> >>> o Rebase on next-20160825
>>> >>> o Add general fix patch for lowmem reserve
>>> >>> o Fix lowmem reserve ratio
>>> >>> o Fix zone span optimizaion per Vlastimil
>>> >>> o Fix pageset initialization
>>> >>> o Change invocation timing on cma_init_reserved_areas()
>>> >>
>>> >> I don't see much information regarding how we interleave between
>>> >> ZONE_CMA and other zones for movable allocation. Is that explained in
>>> >> any of the patch ? The fair zone allocator got removed by
>>> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
>>> >
>>> > Interleaving would not work since the fair zone allocator policy is 
>>> > removed.
>>> > I don't think that it's a big problem because it is just matter of
>>> > timing to fill
>>> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
>>> > any case.
>>> 
>>> Does that mean a CMA allocation will now be slower because in most case we
>>> will need to reclaim ? The zone list will now have ZONE_CMA in the
>>> beginning right ?
>>
>> ZONE_CMA will be used first but I don't think that CMA allocation will
>> be slower. In most case, memory would be fully used (usually
>> by page cache). So, we need reclaim or migration in any case.
>
> Considering that the upstream kernel doesn't allow migration of THP
> pages, this would mean that migrate will fail in most case if we have
> THP enabled and the THP allocation request got satisfied via ZONE_CMA.
> Isn't that going to be a problem ?
>

Even though we have the issues of migration failures due to pinned and
THP pages in ZONE_CMA, overall the code is simpler. IMHO we should get
this upstream now and work on solving those issues later.

You can add for the complete series.

Reviewed-by: Aneesh Kumar K.V 

-aneesh

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Aneesh Kumar K.V]

"Aneesh Kumar K.V"  writes:

> Joonsoo Kim  writes:
>
>> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
>>> Joonsoo Kim  writes:
>>> 
>>> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
>>> > :
>>> >> js1...@gmail.com writes:
>>> >>
>>> >>> From: Joonsoo Kim 
>>> >>>
>>> >>> Hello,
>>> >>>
>>> >>> Changes from v4
>>> >>> o Rebase on next-20160825
>>> >>> o Add general fix patch for lowmem reserve
>>> >>> o Fix lowmem reserve ratio
>>> >>> o Fix zone span optimizaion per Vlastimil
>>> >>> o Fix pageset initialization
>>> >>> o Change invocation timing on cma_init_reserved_areas()
>>> >>
>>> >> I don't see much information regarding how we interleave between
>>> >> ZONE_CMA and other zones for movable allocation. Is that explained in
>>> >> any of the patch ? The fair zone allocator got removed by
>>> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
>>> >
>>> > Interleaving would not work since the fair zone allocator policy is 
>>> > removed.
>>> > I don't think that it's a big problem because it is just matter of
>>> > timing to fill
>>> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
>>> > any case.
>>> 
>>> Does that mean a CMA allocation will now be slower because in most case we
>>> will need to reclaim ? The zone list will now have ZONE_CMA in the
>>> beginning right ?
>>
>> ZONE_CMA will be used first but I don't think that CMA allocation will
>> be slower. In most case, memory would be fully used (usually
>> by page cache). So, we need reclaim or migration in any case.
>
> Considering that the upstream kernel doesn't allow migration of THP
> pages, this would mean that migrate will fail in most case if we have
> THP enabled and the THP allocation request got satisfied via ZONE_CMA.
> Isn't that going to be a problem ?
>

Even though we have the issues of migration failures due to pinned and
THP pages in ZONE_CMA, overall the code is simpler. IMHO we should get
this upstream now and work on solving those issues later.

You can add for the complete series.

Reviewed-by: Aneesh Kumar K.V 

-aneesh

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

On Thu, Sep 01, 2016 at 11:17:23AM +0530, Aneesh Kumar K.V wrote:
> Joonsoo Kim  writes:
> 
> > On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
> >> Joonsoo Kim  writes:
> >> 
> >> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
> >> > :
> >> >> js1...@gmail.com writes:
> >> >>
> >> >>> From: Joonsoo Kim 
> >> >>>
> >> >>> Hello,
> >> >>>
> >> >>> Changes from v4
> >> >>> o Rebase on next-20160825
> >> >>> o Add general fix patch for lowmem reserve
> >> >>> o Fix lowmem reserve ratio
> >> >>> o Fix zone span optimizaion per Vlastimil
> >> >>> o Fix pageset initialization
> >> >>> o Change invocation timing on cma_init_reserved_areas()
> >> >>
> >> >> I don't see much information regarding how we interleave between
> >> >> ZONE_CMA and other zones for movable allocation. Is that explained in
> >> >> any of the patch ? The fair zone allocator got removed by
> >> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
> >> >
> >> > Interleaving would not work since the fair zone allocator policy is 
> >> > removed.
> >> > I don't think that it's a big problem because it is just matter of
> >> > timing to fill
> >> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
> >> > any case.
> >> 
> >> Does that mean a CMA allocation will now be slower because in most case we
> >> will need to reclaim ? The zone list will now have ZONE_CMA in the
> >> beginning right ?
> >
> > ZONE_CMA will be used first but I don't think that CMA allocation will
> > be slower. In most case, memory would be fully used (usually
> > by page cache). So, we need reclaim or migration in any case.
> 
> Considering that the upstream kernel doesn't allow migration of THP
> pages, this would mean that migrate will fail in most case if we have
> THP enabled and the THP allocation request got satisfied via ZONE_CMA.
> Isn't that going to be a problem ?

I think that it is a separate problem. Once we restore utilization of
CMA area, it would become a problem in any case. It is just hidden by
utilization bug and should be handled separately. I guess that it's
not that hard to fix that problem.

Thanks.

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

On Thu, Sep 01, 2016 at 11:17:23AM +0530, Aneesh Kumar K.V wrote:
> Joonsoo Kim  writes:
> 
> > On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
> >> Joonsoo Kim  writes:
> >> 
> >> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
> >> > :
> >> >> js1...@gmail.com writes:
> >> >>
> >> >>> From: Joonsoo Kim 
> >> >>>
> >> >>> Hello,
> >> >>>
> >> >>> Changes from v4
> >> >>> o Rebase on next-20160825
> >> >>> o Add general fix patch for lowmem reserve
> >> >>> o Fix lowmem reserve ratio
> >> >>> o Fix zone span optimizaion per Vlastimil
> >> >>> o Fix pageset initialization
> >> >>> o Change invocation timing on cma_init_reserved_areas()
> >> >>
> >> >> I don't see much information regarding how we interleave between
> >> >> ZONE_CMA and other zones for movable allocation. Is that explained in
> >> >> any of the patch ? The fair zone allocator got removed by
> >> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
> >> >
> >> > Interleaving would not work since the fair zone allocator policy is 
> >> > removed.
> >> > I don't think that it's a big problem because it is just matter of
> >> > timing to fill
> >> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
> >> > any case.
> >> 
> >> Does that mean a CMA allocation will now be slower because in most case we
> >> will need to reclaim ? The zone list will now have ZONE_CMA in the
> >> beginning right ?
> >
> > ZONE_CMA will be used first but I don't think that CMA allocation will
> > be slower. In most case, memory would be fully used (usually
> > by page cache). So, we need reclaim or migration in any case.
> 
> Considering that the upstream kernel doesn't allow migration of THP
> pages, this would mean that migrate will fail in most case if we have
> THP enabled and the THP allocation request got satisfied via ZONE_CMA.
> Isn't that going to be a problem ?

I think that it is a separate problem. Once we restore utilization of
CMA area, it would become a problem in any case. It is just hidden by
utilization bug and should be handled separately. I guess that it's
not that hard to fix that problem.

Thanks.

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Aneesh Kumar K.V]

Joonsoo Kim  writes:

> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
>> Joonsoo Kim  writes:
>> 
>> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
>> > :
>> >> js1...@gmail.com writes:
>> >>
>> >>> From: Joonsoo Kim 
>> >>>
>> >>> Hello,
>> >>>
>> >>> Changes from v4
>> >>> o Rebase on next-20160825
>> >>> o Add general fix patch for lowmem reserve
>> >>> o Fix lowmem reserve ratio
>> >>> o Fix zone span optimizaion per Vlastimil
>> >>> o Fix pageset initialization
>> >>> o Change invocation timing on cma_init_reserved_areas()
>> >>
>> >> I don't see much information regarding how we interleave between
>> >> ZONE_CMA and other zones for movable allocation. Is that explained in
>> >> any of the patch ? The fair zone allocator got removed by
>> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
>> >
>> > Interleaving would not work since the fair zone allocator policy is 
>> > removed.
>> > I don't think that it's a big problem because it is just matter of
>> > timing to fill
>> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
>> > any case.
>> 
>> Does that mean a CMA allocation will now be slower because in most case we
>> will need to reclaim ? The zone list will now have ZONE_CMA in the
>> beginning right ?
>
> ZONE_CMA will be used first but I don't think that CMA allocation will
> be slower. In most case, memory would be fully used (usually
> by page cache). So, we need reclaim or migration in any case.

Considering that the upstream kernel doesn't allow migration of THP
pages, this would mean that migrate will fail in most case if we have
THP enabled and the THP allocation request got satisfied via ZONE_CMA.
Isn't that going to be a problem ?

-aneesh

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Aneesh Kumar K.V]

Joonsoo Kim  writes:

> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
>> Joonsoo Kim  writes:
>> 
>> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
>> > :
>> >> js1...@gmail.com writes:
>> >>
>> >>> From: Joonsoo Kim 
>> >>>
>> >>> Hello,
>> >>>
>> >>> Changes from v4
>> >>> o Rebase on next-20160825
>> >>> o Add general fix patch for lowmem reserve
>> >>> o Fix lowmem reserve ratio
>> >>> o Fix zone span optimizaion per Vlastimil
>> >>> o Fix pageset initialization
>> >>> o Change invocation timing on cma_init_reserved_areas()
>> >>
>> >> I don't see much information regarding how we interleave between
>> >> ZONE_CMA and other zones for movable allocation. Is that explained in
>> >> any of the patch ? The fair zone allocator got removed by
>> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
>> >
>> > Interleaving would not work since the fair zone allocator policy is 
>> > removed.
>> > I don't think that it's a big problem because it is just matter of
>> > timing to fill
>> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
>> > any case.
>> 
>> Does that mean a CMA allocation will now be slower because in most case we
>> will need to reclaim ? The zone list will now have ZONE_CMA in the
>> beginning right ?
>
> ZONE_CMA will be used first but I don't think that CMA allocation will
> be slower. In most case, memory would be fully used (usually
> by page cache). So, we need reclaim or migration in any case.

Considering that the upstream kernel doesn't allow migration of THP
pages, this would mean that migrate will fail in most case if we have
THP enabled and the THP allocation request got satisfied via ZONE_CMA.
Isn't that going to be a problem ?

-aneesh

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
> Joonsoo Kim  writes:
> 
> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
> > :
> >> js1...@gmail.com writes:
> >>
> >>> From: Joonsoo Kim 
> >>>
> >>> Hello,
> >>>
> >>> Changes from v4
> >>> o Rebase on next-20160825
> >>> o Add general fix patch for lowmem reserve
> >>> o Fix lowmem reserve ratio
> >>> o Fix zone span optimizaion per Vlastimil
> >>> o Fix pageset initialization
> >>> o Change invocation timing on cma_init_reserved_areas()
> >>
> >> I don't see much information regarding how we interleave between
> >> ZONE_CMA and other zones for movable allocation. Is that explained in
> >> any of the patch ? The fair zone allocator got removed by
> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
> >
> > Interleaving would not work since the fair zone allocator policy is removed.
> > I don't think that it's a big problem because it is just matter of
> > timing to fill
> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
> > any case.
> 
> Does that mean a CMA allocation will now be slower because in most case we
> will need to reclaim ? The zone list will now have ZONE_CMA in the
> beginning right ?

ZONE_CMA will be used first but I don't think that CMA allocation will
be slower. In most case, memory would be fully used (usually
by page cache). So, we need reclaim or migration in any case.

Thanks.

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote:
> Joonsoo Kim  writes:
> 
> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V 
> > :
> >> js1...@gmail.com writes:
> >>
> >>> From: Joonsoo Kim 
> >>>
> >>> Hello,
> >>>
> >>> Changes from v4
> >>> o Rebase on next-20160825
> >>> o Add general fix patch for lowmem reserve
> >>> o Fix lowmem reserve ratio
> >>> o Fix zone span optimizaion per Vlastimil
> >>> o Fix pageset initialization
> >>> o Change invocation timing on cma_init_reserved_areas()
> >>
> >> I don't see much information regarding how we interleave between
> >> ZONE_CMA and other zones for movable allocation. Is that explained in
> >> any of the patch ? The fair zone allocator got removed by
> >> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
> >
> > Interleaving would not work since the fair zone allocator policy is removed.
> > I don't think that it's a big problem because it is just matter of
> > timing to fill
> > up the memory. Eventually, memory on ZONE_CMA will be fully used in
> > any case.
> 
> Does that mean a CMA allocation will now be slower because in most case we
> will need to reclaim ? The zone list will now have ZONE_CMA in the
> beginning right ?

ZONE_CMA will be used first but I don't think that CMA allocation will
be slower. In most case, memory would be fully used (usually
by page cache). So, we need reclaim or migration in any case.

Thanks.

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Aneesh Kumar K.V]

Joonsoo Kim  writes:

> 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V :
>> js1...@gmail.com writes:
>>
>>> From: Joonsoo Kim 
>>>
>>> Hello,
>>>
>>> Changes from v4
>>> o Rebase on next-20160825
>>> o Add general fix patch for lowmem reserve
>>> o Fix lowmem reserve ratio
>>> o Fix zone span optimizaion per Vlastimil
>>> o Fix pageset initialization
>>> o Change invocation timing on cma_init_reserved_areas()
>>
>> I don't see much information regarding how we interleave between
>> ZONE_CMA and other zones for movable allocation. Is that explained in
>> any of the patch ? The fair zone allocator got removed by
>> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
>
> Interleaving would not work since the fair zone allocator policy is removed.
> I don't think that it's a big problem because it is just matter of
> timing to fill
> up the memory. Eventually, memory on ZONE_CMA will be fully used in
> any case.

Does that mean a CMA allocation will now be slower because in most case we
will need to reclaim ? The zone list will now have ZONE_CMA in the
beginning right ?

-aneesh

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Aneesh Kumar K.V]

Joonsoo Kim  writes:

> 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V :
>> js1...@gmail.com writes:
>>
>>> From: Joonsoo Kim 
>>>
>>> Hello,
>>>
>>> Changes from v4
>>> o Rebase on next-20160825
>>> o Add general fix patch for lowmem reserve
>>> o Fix lowmem reserve ratio
>>> o Fix zone span optimizaion per Vlastimil
>>> o Fix pageset initialization
>>> o Change invocation timing on cma_init_reserved_areas()
>>
>> I don't see much information regarding how we interleave between
>> ZONE_CMA and other zones for movable allocation. Is that explained in
>> any of the patch ? The fair zone allocator got removed by
>> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05
>
> Interleaving would not work since the fair zone allocator policy is removed.
> I don't think that it's a big problem because it is just matter of
> timing to fill
> up the memory. Eventually, memory on ZONE_CMA will be fully used in
> any case.

Does that mean a CMA allocation will now be slower because in most case we
will need to reclaim ? The zone list will now have ZONE_CMA in the
beginning right ?

-aneesh

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V :
> js1...@gmail.com writes:
>
>> From: Joonsoo Kim 
>>
>> Hello,
>>
>> Changes from v4
>> o Rebase on next-20160825
>> o Add general fix patch for lowmem reserve
>> o Fix lowmem reserve ratio
>> o Fix zone span optimizaion per Vlastimil
>> o Fix pageset initialization
>> o Change invocation timing on cma_init_reserved_areas()
>
> I don't see much information regarding how we interleave between
> ZONE_CMA and other zones for movable allocation. Is that explained in
> any of the patch ? The fair zone allocator got removed by
> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05

Interleaving would not work since the fair zone allocator policy is removed.
I don't think that it's a big problem because it is just matter of
timing to fill
up the memory. Eventually, memory on ZONE_CMA will be fully used in
any case.

Thanks.

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V :
> js1...@gmail.com writes:
>
>> From: Joonsoo Kim 
>>
>> Hello,
>>
>> Changes from v4
>> o Rebase on next-20160825
>> o Add general fix patch for lowmem reserve
>> o Fix lowmem reserve ratio
>> o Fix zone span optimizaion per Vlastimil
>> o Fix pageset initialization
>> o Change invocation timing on cma_init_reserved_areas()
>
> I don't see much information regarding how we interleave between
> ZONE_CMA and other zones for movable allocation. Is that explained in
> any of the patch ? The fair zone allocator got removed by
> e6cbd7f2efb433d717af72aa8510a9db6f7a7e05

Interleaving would not work since the fair zone allocator policy is removed.
I don't think that it's a big problem because it is just matter of
timing to fill
up the memory. Eventually, memory on ZONE_CMA will be fully used in
any case.

Thanks.

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Aneesh Kumar K.V]

js1...@gmail.com writes:

> From: Joonsoo Kim 
>
> Hello,
>
> Changes from v4
> o Rebase on next-20160825
> o Add general fix patch for lowmem reserve
> o Fix lowmem reserve ratio
> o Fix zone span optimizaion per Vlastimil
> o Fix pageset initialization
> o Change invocation timing on cma_init_reserved_areas()

I don't see much information regarding how we interleave between
ZONE_CMA and other zones for movable allocation. Is that explained in
any of the patch ? The fair zone allocator got removed by
e6cbd7f2efb433d717af72aa8510a9db6f7a7e05 

-aneesh

Re: [PATCH v5 0/6] Introduce ZONE_CMA

[Aneesh Kumar K.V]

js1...@gmail.com writes:

> From: Joonsoo Kim 
>
> Hello,
>
> Changes from v4
> o Rebase on next-20160825
> o Add general fix patch for lowmem reserve
> o Fix lowmem reserve ratio
> o Fix zone span optimizaion per Vlastimil
> o Fix pageset initialization
> o Change invocation timing on cma_init_reserved_areas()

I don't see much information regarding how we interleave between
ZONE_CMA and other zones for movable allocation. Is that explained in
any of the patch ? The fair zone allocator got removed by
e6cbd7f2efb433d717af72aa8510a9db6f7a7e05 

-aneesh

[PATCH v5 0/6] Introduce ZONE_CMA

[js1304]

From: Joonsoo Kim 

Hello,

Changes from v4
o Rebase on next-20160825
o Add general fix patch for lowmem reserve
o Fix lowmem reserve ratio
o Fix zone span optimizaion per Vlastimil
o Fix pageset initialization
o Change invocation timing on cma_init_reserved_areas()

Changes from v3
o Rebase on next-20160805
o Split first patch per Vlastimil
o Remove useless function parameter per Vlastimil
o Add code comment per Vlastimil
o Add following description on cover-letter

This is the 5th version of ZONE_CMA patchset. Most of changes are
due to rebase and some minor fixes.

CMA has many problems and I mentioned them on the bottom of the
cover letter. These problems comes from limitation of CMA memory that
should be always migratable for device usage. I think that introducing
a new zone is the best approach to solve them. Here are the reasons.

Zone is introduced to solve some issues due to H/W addressing limitation.
MM subsystem is implemented to work efficiently with these zones.
Allocation/reclaim logic in MM consider this limitation very much.
What I did in this patchset is introducing a new zone and extending zone's
concept slightly. New concept is that zone can have not only H/W addressing
limitation but also S/W limitation to guarantee page migration.
This concept is originated from ZONE_MOVABLE and it works well
for a long time. So, ZONE_CMA should not be special at this moment.

There is a major concern from Mel that ZONE_MOVABLE which has
S/W limitation causes highmem/lowmem problem. Highmem/lowmem problem is
that some of memory cannot be usable for kernel memory due to limitation
of the zone. It causes to break LRU ordering and makes hard to find kernel
usable memory when memory pressure.

However, important point is that this problem doesn't come from
implementation detail (ZONE_MOVABLE/MIGRATETYPE). Even if we implement it
by MIGRATETYPE instead of by ZONE_MOVABLE, we cannot use that type of
memory for kernel allocation because it isn't migratable. So, it will cause
to break LRU ordering, too. We cannot avoid the problem in any case.
Therefore, we should focus on which solution is better for maintainance
and not intrusive for MM subsystem.

In this viewpoint, I think that zone approach is better. As mentioned
earlier, MM subsystem already have many infrastructures to deal with
zone's H/W addressing limitation. Adding S/W limitation on zone concept
and adding a new zone doesn't change anything. It will work by itself.
My patchset can remove many hooks related to CMA area management in MM
while solving the problems. More hooks are required to solve the problems
if we choose MIGRATETYPE approach.

Although Mel withdrew the review, Vlastimil expressed an agreement on this
new zone approach [6].

 "I realize I differ here from much more experienced mm guys, and will
 probably deservingly regret it later on, but I think that the ZONE_CMA
 approach could work indeed better than current MIGRATE_CMA pageblocks."

If anyone has a different opinion, please let me know.

Thanks.


Changes from v2
o Rebase on next-20160525
o No other changes except following description

There was a discussion with Mel [5] after LSF/MM 2016. I could summarise
it to help merge decision but it's better to read by yourself since
if I summarise it, it would be biased for me. But, if anyone hope
the summary, I will do it. :)

Anyway, Mel's position on this patchset seems to be neutral. He saids:
"I'm not going to outright NAK your series but I won't ACK it either"

We can fix the problems with any approach but I hope to go a new zone
approach because it is less error-prone. It reduces some corner case
handling for now and remove need for potential corner case handling to fix
problems.

Note that our company is already using ZONE_CMA and there is no problem.

If anyone has a different opinion, please let me know and let's discuss
together.

Andrew, if there is something to do for merge, please let me know.

Changes from v1
o Separate some patches which deserve to submit independently
o Modify description to reflect current kernel state
(e.g. high-order watermark problem disappeared by Mel's work)
o Don't increase SECTION_SIZE_BITS to make a room in page flags
(detailed reason is on the patch that adds ZONE_CMA)
o Adjust ZONE_CMA population code

This series try to solve problems of current CMA implementation.

CMA is introduced to provide physically contiguous pages at runtime
without exclusive reserved memory area. But, current implementation
works like as previous reserved memory approach, because freepages
on CMA region are used only if there is no movable freepage. In other
words, freepages on CMA region are only used as fallback. In that
situation where freepages on CMA region are used as fallback, kswapd
would be woken up easily since there is no unmovable and reclaimable
freepage, too. If kswapd starts to reclaim memory, fallback allocation
to MIGRATE_CMA doesn't occur any more since movable freepages 

[PATCH v5 0/6] Introduce ZONE_CMA

[js1304]

From: Joonsoo Kim 

Hello,

Changes from v4
o Rebase on next-20160825
o Add general fix patch for lowmem reserve
o Fix lowmem reserve ratio
o Fix zone span optimizaion per Vlastimil
o Fix pageset initialization
o Change invocation timing on cma_init_reserved_areas()

Changes from v3
o Rebase on next-20160805
o Split first patch per Vlastimil
o Remove useless function parameter per Vlastimil
o Add code comment per Vlastimil
o Add following description on cover-letter

This is the 5th version of ZONE_CMA patchset. Most of changes are
due to rebase and some minor fixes.

CMA has many problems and I mentioned them on the bottom of the
cover letter. These problems comes from limitation of CMA memory that
should be always migratable for device usage. I think that introducing
a new zone is the best approach to solve them. Here are the reasons.

Zone is introduced to solve some issues due to H/W addressing limitation.
MM subsystem is implemented to work efficiently with these zones.
Allocation/reclaim logic in MM consider this limitation very much.
What I did in this patchset is introducing a new zone and extending zone's
concept slightly. New concept is that zone can have not only H/W addressing
limitation but also S/W limitation to guarantee page migration.
This concept is originated from ZONE_MOVABLE and it works well
for a long time. So, ZONE_CMA should not be special at this moment.

There is a major concern from Mel that ZONE_MOVABLE which has
S/W limitation causes highmem/lowmem problem. Highmem/lowmem problem is
that some of memory cannot be usable for kernel memory due to limitation
of the zone. It causes to break LRU ordering and makes hard to find kernel
usable memory when memory pressure.

However, important point is that this problem doesn't come from
implementation detail (ZONE_MOVABLE/MIGRATETYPE). Even if we implement it
by MIGRATETYPE instead of by ZONE_MOVABLE, we cannot use that type of
memory for kernel allocation because it isn't migratable. So, it will cause
to break LRU ordering, too. We cannot avoid the problem in any case.
Therefore, we should focus on which solution is better for maintainance
and not intrusive for MM subsystem.

In this viewpoint, I think that zone approach is better. As mentioned
earlier, MM subsystem already have many infrastructures to deal with
zone's H/W addressing limitation. Adding S/W limitation on zone concept
and adding a new zone doesn't change anything. It will work by itself.
My patchset can remove many hooks related to CMA area management in MM
while solving the problems. More hooks are required to solve the problems
if we choose MIGRATETYPE approach.

Although Mel withdrew the review, Vlastimil expressed an agreement on this
new zone approach [6].

 "I realize I differ here from much more experienced mm guys, and will
 probably deservingly regret it later on, but I think that the ZONE_CMA
 approach could work indeed better than current MIGRATE_CMA pageblocks."

If anyone has a different opinion, please let me know.

Thanks.


Changes from v2
o Rebase on next-20160525
o No other changes except following description

There was a discussion with Mel [5] after LSF/MM 2016. I could summarise
it to help merge decision but it's better to read by yourself since
if I summarise it, it would be biased for me. But, if anyone hope
the summary, I will do it. :)

Anyway, Mel's position on this patchset seems to be neutral. He saids:
"I'm not going to outright NAK your series but I won't ACK it either"

We can fix the problems with any approach but I hope to go a new zone
approach because it is less error-prone. It reduces some corner case
handling for now and remove need for potential corner case handling to fix
problems.

Note that our company is already using ZONE_CMA and there is no problem.

If anyone has a different opinion, please let me know and let's discuss
together.

Andrew, if there is something to do for merge, please let me know.

Changes from v1
o Separate some patches which deserve to submit independently
o Modify description to reflect current kernel state
(e.g. high-order watermark problem disappeared by Mel's work)
o Don't increase SECTION_SIZE_BITS to make a room in page flags
(detailed reason is on the patch that adds ZONE_CMA)
o Adjust ZONE_CMA population code

This series try to solve problems of current CMA implementation.

CMA is introduced to provide physically contiguous pages at runtime
without exclusive reserved memory area. But, current implementation
works like as previous reserved memory approach, because freepages
on CMA region are used only if there is no movable freepage. In other
words, freepages on CMA region are only used as fallback. In that
situation where freepages on CMA region are used as fallback, kswapd
would be woken up easily since there is no unmovable and reclaimable
freepage, too. If kswapd starts to reclaim memory, fallback allocation
to MIGRATE_CMA doesn't occur any more since movable freepages are
already refilled by