[LSF/MM TOPIC] Improving CMA

[LSF/MM TOPIC] Improving CMA

[Laura Abbott]

There have been a number of patch series posted designed to improve various
aspects of CMA. A sampling:

https://lkml.org/lkml/2014/10/15/623
http://marc.info/?l=linux-mm&m=141571797202006&w=2
https://lkml.org/lkml/2014/6/26/549

As far as I can tell, these are all trying to fix real problems with CMA but
none of them have moved forward very much from what I can tell. The goal of
this session would be to come out with an agreement on what are the biggest
problems with CMA and the best ways to solve them.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: [Lsf-pc] [LSF/MM TOPIC] Improving CMA

[Mel Gorman]

On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
> There have been a number of patch series posted designed to improve various
> aspects of CMA. A sampling:
> 
> https://lkml.org/lkml/2014/10/15/623
> http://marc.info/?l=linux-mm&m=141571797202006&w=2
> https://lkml.org/lkml/2014/6/26/549
> 
> As far as I can tell, these are all trying to fix real problems with CMA but
> none of them have moved forward very much from what I can tell. The goal of
> this session would be to come out with an agreement on what are the biggest
> problems with CMA and the best ways to solve them.
> 

I think this is a good topic. Some of the issues have been brought up before
at LSF/MM but they never made that much traction so it's worth revisiting. I
haven't been paying close attention to the mailing list discussions but
I've been a little worried that the page allocator paths are turning into
a bigger and bigger mess. I'm also a bit worried that options such as
migrating pages out of CMA areas that are about to be pinned for having
callback options to forcibly free pages never went anywhere.

-- 
Mel Gorman
SUSE Labs

--
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: [Lsf-pc] [LSF/MM TOPIC] Improving CMA

[Gioh Kim]

2014-11-25 i??i?? 8:32i?? Mel Gorman i?'(e??) i?' e,?:
> On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
>> There have been a number of patch series posted designed to improve various
>> aspects of CMA. A sampling:
>>
>> https://lkml.org/lkml/2014/10/15/623
>> http://marc.info/?l=linux-mm&m=141571797202006&w=2
>> https://lkml.org/lkml/2014/6/26/549
>>
>> As far as I can tell, these are all trying to fix real problems with CMA but
>> none of them have moved forward very much from what I can tell. The goal of
>> this session would be to come out with an agreement on what are the biggest
>> problems with CMA and the best ways to solve them.
>>
>
> I think this is a good topic. Some of the issues have been brought up before
> at LSF/MM but they never made that much traction so it's worth revisiting. I
> haven't been paying close attention to the mailing list discussions but
> I've been a little worried that the page allocator paths are turning into
> a bigger and bigger mess. I'm also a bit worried that options such as
> migrating pages out of CMA areas that are about to be pinned for having
> callback options to forcibly free pages never went anywhere.
>


I have two question.

First, is GCMA able to replace CMA? It's news to me.
I need some time to check GCMA.

Second, is CMA popular enough to change allocator path?
Yes, I need it.
But I don't know any company uses it, and nobody seems to have interest in it.

--
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: [Lsf-pc] [LSF/MM TOPIC] Improving CMA

[SeongJae Park]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2123 bytes --]

Hi Gioh,

On Wed, 26 Nov 2014, Gioh Kim wrote:

>
>
> 2014-11-25 i??i?? 8:32i?? Mel Gorman i?'(e??) i?' e,?:
>> On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
>>> There have been a number of patch series posted designed to improve 
>>> various
>>> aspects of CMA. A sampling:
>>> 
>>> https://lkml.org/lkml/2014/10/15/623
>>> http://marc.info/?l=linux-mm&m=141571797202006&w=2
>>> https://lkml.org/lkml/2014/6/26/549
>>> 
>>> As far as I can tell, these are all trying to fix real problems with CMA 
>>> but
>>> none of them have moved forward very much from what I can tell. The goal 
>>> of
>>> this session would be to come out with an agreement on what are the 
>>> biggest
>>> problems with CMA and the best ways to solve them.
>>> 
>> 
>> I think this is a good topic. Some of the issues have been brought up 
>> before
>> at LSF/MM but they never made that much traction so it's worth revisiting. 
>> I
>> haven't been paying close attention to the mailing list discussions but
>> I've been a little worried that the page allocator paths are turning into
>> a bigger and bigger mess. I'm also a bit worried that options such as
>> migrating pages out of CMA areas that are about to be pinned for having
>> callback options to forcibly free pages never went anywhere.
>> 
>
>
> I have two question.
>
> First, is GCMA able to replace CMA? It's news to me.

Yes, it can. GCMA could replace or co-exist and be used selectively with 
CMA. You could replace CMA with GCMA by simply changing 
cma_declare_contiguous() function call with gcma_declare_contiguous().

> I need some time to check GCMA.

1st RFC of GCMA was posted on linux-mm mailing list as Laura linked and 
you could get whole code from gcma/rfc/v1 tag of 
https://github.com/sjp38/linux.gcma. It would great for me if you could 
check it and give me any feedback because GCMA have lots of TODO / Future 
plans and 2nd RFC is acively developing already.

Thanks,
SeongJae Park

>
> Second, is CMA popular enough to change allocator path?
> Yes, I need it.
> But I don't know any company uses it, and nobody seems to have interest in 
> it.
>

答复: [Lsf-pc] [LSF/MM TOPIC] Improving CMA

[朱辉]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1944 bytes --]


________________________________________
发件人: Gioh Kim <gioh.kim@lge.com>
发送时间: 2014年11月26日 12:25
收件人: Mel Gorman; Laura Abbott
抄送: lsf-pc@lists.linux-foundation.org; linux-mm@kvack.org; SeongJae Park; minchan@kernel.org; 朱辉; iamjoonsoo.kim@lge.com
主题: Re: [Lsf-pc] [LSF/MM TOPIC] Improving CMA

2014-11-25 오후 8:32에 Mel Gorman 이(가) 쓴 글:
> On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
>> There have been a number of patch series posted designed to improve various
>> aspects of CMA. A sampling:
>>
>> https://lkml.org/lkml/2014/10/15/623
>> http://marc.info/?l=linux-mm&m=141571797202006&w=2
>> https://lkml.org/lkml/2014/6/26/549
>>
>> As far as I can tell, these are all trying to fix real problems with CMA but
>> none of them have moved forward very much from what I can tell. The goal of
>> this session would be to come out with an agreement on what are the biggest
>> problems with CMA and the best ways to solve them.
>>
>
> I think this is a good topic. Some of the issues have been brought up before
> at LSF/MM but they never made that much traction so it's worth revisiting. I
> haven't been paying close attention to the mailing list discussions but
> I've been a little worried that the page allocator paths are turning into
> a bigger and bigger mess. I'm also a bit worried that options such as
> migrating pages out of CMA areas that are about to be pinned for having
> callback options to forcibly free pages never went anywhere.
>

> I have two question.
>
> First, is GCMA able to replace CMA? It's news to me.
> I need some time to check GCMA.
>
> Second, is CMA popular enough to change allocator path?
> Yes, I need it.
> But I don't know any company uses it, and nobody seems to have interest in
> it.

We (xiaomi) use it in our new mibox.

Thanks,
HuiN‹§²æìr¸›zǧu©ž²Æ {\b­†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨­è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ

Re: [LSF/MM TOPIC] Improving CMA

[Minchan Kim]

Hello Laura,

On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
> There have been a number of patch series posted designed to improve various
> aspects of CMA. A sampling:
> 
> https://lkml.org/lkml/2014/10/15/623
> http://marc.info/?l=linux-mm&m=141571797202006&w=2
> https://lkml.org/lkml/2014/6/26/549
> 
> As far as I can tell, these are all trying to fix real problems with CMA but
> none of them have moved forward very much from what I can tell. The goal of
> this session would be to come out with an agreement on what are the biggest
> problems with CMA and the best ways to solve them.

Thanks for the proposal.
Yes, CMA has broken for a long time.

1. Memory allocation for CMA area -> Broken
2. Memory reclaim for CMA area -> Broken
3. CMA allocation latency -> Broken
4. CMA allocation success guarantee -> Broken.

I believe there is no real product to use vanilla CMA in mainline
without any hack.

Recently, there are some efforts to fix 1 but patchset I have seen hurt
allocator's hot path which is really not what I want. Instead, I suggested
to use movalbe zone. It would help 1 and 2 problem and make mm code simple
so I think it's worth to try before making mm code more bloat with CMA hooks.
https://lkml.org/lkml/2014/11/4/55

However, we don't have a nice idea to solve 3 and 4 still.
There were some trying to migrate CMA page out when someone try to pin
CMA page via GUP but it's not a perfect solution. We should take care of
indirect object dependency(ex, obj A gets obj B, obj B gets obj C)
so page located in obj C will not release until obj B release and
obj B doesn't relase until obj A released). It means we should
take care of get_page as well as GUP. It's terrible.

Recently, I and SeongJae posted GCMA(Guaranteed CMA) which is a idea
to solve above all problems. https://lkml.org/lkml/2014/10/15/623
But it apparently has tradeoff. So, our goal is to recommend GCMA
if you want to make sure fast allocation success. Or, use CMA
if you have fallback scheme of failure of allocation, if you
are okay to allocation latency(a few seconds) sometime, if you
should use really big contiguous memory.

Anyway, I have an interest on this topic and want to attend.

Thanks.

> 
> Thanks,
> Laura
> 
> -- 
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> --
> 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>

-- 
Kind regards,
Minchan Kim

--
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: [Lsf-pc] [LSF/MM TOPIC] Improving CMA

[Laura Abbott]

On 11/25/2014 8:25 PM, Gioh Kim wrote:
>
>
> 2014-11-25 i??i?? 8:32i?? Mel Gorman i?'(e??) i?' e,?:
>> On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
>>> There have been a number of patch series posted designed to improve various
>>> aspects of CMA. A sampling:
>>>
>>> https://lkml.org/lkml/2014/10/15/623
>>> http://marc.info/?l=linux-mm&m=141571797202006&w=2
>>> https://lkml.org/lkml/2014/6/26/549
>>>
>>> As far as I can tell, these are all trying to fix real problems with CMA but
>>> none of them have moved forward very much from what I can tell. The goal of
>>> this session would be to come out with an agreement on what are the biggest
>>> problems with CMA and the best ways to solve them.
>>>
>>
>> I think this is a good topic. Some of the issues have been brought up before
>> at LSF/MM but they never made that much traction so it's worth revisiting. I
>> haven't been paying close attention to the mailing list discussions but
>> I've been a little worried that the page allocator paths are turning into
>> a bigger and bigger mess. I'm also a bit worried that options such as
>> migrating pages out of CMA areas that are about to be pinned for having
>> callback options to forcibly free pages never went anywhere.
>>
>
>
> I have two question.
>
> First, is GCMA able to replace CMA? It's news to me.
> I need some time to check GCMA.
>
> Second, is CMA popular enough to change allocator path?
> Yes, I need it.
> But I don't know any company uses it, and nobody seems to have interest in it.

We use it very heavily in our devices and I don't think it's a stretch to
say we depend on it to actually ship a product. I suspect this may be the case
with other companies as well. It may not be as obvious if CMA is being used
because much of the work is still out of tree. I think if CMA performance
metrics were improved it would see more obvious traction as well.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: [LSF/MM TOPIC] Improving CMA

[Joonsoo Kim]

On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
> There have been a number of patch series posted designed to improve various
> aspects of CMA. A sampling:
> 
> https://lkml.org/lkml/2014/10/15/623
> http://marc.info/?l=linux-mm&m=141571797202006&w=2
> https://lkml.org/lkml/2014/6/26/549
> 
> As far as I can tell, these are all trying to fix real problems with CMA but
> none of them have moved forward very much from what I can tell. The goal of
> this session would be to come out with an agreement on what are the biggest
> problems with CMA and the best ways to solve them.

I also tried to solve problem from CMA, that is, reserved memory
utilization.

https://lkml.org/lkml/2014/5/28/64

While playing that patchset, I found serious problem about free page
counting, so I stopped to develop it for a while and tried to fix it.
Now, it is fixed by me and I can continue my patchset.

https://lkml.org/lkml/2014/10/31/69

I heard that Minchan suggests new CMA zone like movable zone, and, I
think that it would be the way to go. But, it would be a long-term goal
and I'd like to solve utilization problem with my patchset for now.
It is the biggest issue and it already forces someone to develop
out of tree solution. It's not good that out of tree solution is used
more and more in the product so I'd like to fix it quickly at first
stage.

I think that CMA have big potential. If we fix problems of CMA
completely, it can be used for many places. One such case in my mind
is hugetlb or THP. Until now, hugetlb uses reserved approach, that is
very inefficient. System administrator carefully set the number of
reserved hugepage according to whole system workload. And application
can't use it freely, because it is very limited and managed resource.
If we use CMA for hugetlb, we can easily allocate hugepage and
application can use hugepages more freely.

Anyway, I'd like to attend LSF/MM and discuss this topic.

Thanks.

--
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: [LSF/MM TOPIC] Improving CMA

[Gioh Kim]

2014-11-27 i??i?? 3:12i?? Joonsoo Kim i?'(e??) i?' e,?:
> On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
>> There have been a number of patch series posted designed to improve various
>> aspects of CMA. A sampling:
>>
>> https://lkml.org/lkml/2014/10/15/623
>> http://marc.info/?l=linux-mm&m=141571797202006&w=2
>> https://lkml.org/lkml/2014/6/26/549
>>
>> As far as I can tell, these are all trying to fix real problems with CMA but
>> none of them have moved forward very much from what I can tell. The goal of
>> this session would be to come out with an agreement on what are the biggest
>> problems with CMA and the best ways to solve them.
>
> I also tried to solve problem from CMA, that is, reserved memory
> utilization.
>
> https://lkml.org/lkml/2014/5/28/64
>
> While playing that patchset, I found serious problem about free page
> counting, so I stopped to develop it for a while and tried to fix it.
> Now, it is fixed by me and I can continue my patchset.
>
> https://lkml.org/lkml/2014/10/31/69
>
> I heard that Minchan suggests new CMA zone like movable zone, and, I
> think that it would be the way to go. But, it would be a long-term goal
> and I'd like to solve utilization problem with my patchset for now.
> It is the biggest issue and it already forces someone to develop
> out of tree solution. It's not good that out of tree solution is used
> more and more in the product so I'd like to fix it quickly at first
> stage.
>
> I think that CMA have big potential. If we fix problems of CMA
> completely, it can be used for many places. One such case in my mind
> is hugetlb or THP. Until now, hugetlb uses reserved approach, that is
> very inefficient. System administrator carefully set the number of
> reserved hugepage according to whole system workload. And application
> can't use it freely, because it is very limited and managed resource.
> If we use CMA for hugetlb, we can easily allocate hugepage and
> application can use hugepages more freely.
>
> Anyway, I'd like to attend LSF/MM and discuss this topic.
>
> Thanks.
>

Until now, I've used CMA with 2 out-of-tree patches:
1. https://lkml.org/lkml/2012/8/31/313 : Laura's patch
2. https://lkml.org/lkml/2014/5/28/64 : Joonsoo's patch

And one merged patch by me: https://lkml.org/lkml/2014/9/4/78

With them, my platform could've worked but it still had free-page-counting problem.

I think if Joonsoo's patch [2] is merged into mainline, CMA can be stable and useful.
Allocation latency Minchan mentioned is not problem for my platform.
CMA allocation is not often and limited to only one drivers.

Allocation guarantee is, I hope, fixed with my patch (https://lkml.org/lkml/2014/9/4/78) at least in my platform.
My platform had worked for several hours but it lacks heavy load test.
I have a plan to use CMA for massive product next year.

I'd like to attend LSF/MM and discuss this topic too.

--
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: [LSF/MM TOPIC] Improving CMA

[Wanpeng Li]

On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
>There have been a number of patch series posted designed to improve various
>aspects of CMA. A sampling:
>
>https://lkml.org/lkml/2014/10/15/623
>http://marc.info/?l=linux-mm&m=141571797202006&w=2
>https://lkml.org/lkml/2014/6/26/549
>
>As far as I can tell, these are all trying to fix real problems with CMA but
>none of them have moved forward very much from what I can tell. The goal of
>this session would be to come out with an agreement on what are the biggest
>problems with CMA and the best ways to solve them.

I'd like to attend LSF/MM and discuss this interesting topic too.

Regards,
Wanpeng Li 

>
>Thanks,
>Laura
>
>-- 
>Qualcomm Innovation Center, Inc.
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>a Linux Foundation Collaborative Project
>
>--
>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>

--
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: [Lsf-pc] [LSF/MM TOPIC] Improving CMA

[James Bottomley]

On Thu, 2014-11-27 at 15:56 +0800, Wanpeng Li wrote:
> On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
> >There have been a number of patch series posted designed to improve various
> >aspects of CMA. A sampling:
> >
> >https://lkml.org/lkml/2014/10/15/623
> >http://marc.info/?l=linux-mm&m=141571797202006&w=2
> >https://lkml.org/lkml/2014/6/26/549
> >
> >As far as I can tell, these are all trying to fix real problems with CMA but
> >none of them have moved forward very much from what I can tell. The goal of
> >this session would be to come out with an agreement on what are the biggest
> >problems with CMA and the best ways to solve them.
> 
> I'd like to attend LSF/MM and discuss this interesting topic too.

OK, so please send an ATTEND email as requested by the CFP.  The reason
"me too" on topic emails doesn't work is twofold:  Firstly because you
haven't given the programme committee any indication of what you'd be
able to contribute and secondly, when constructing the lists of requests
we tend to fold all the threads up under the primary email, so it gets
lost administratively.

James


--
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>

[LSF/MM ATTEND] Improving CMA

[Joonsoo Kim]

On Thu, Nov 27, 2014 at 03:12:04PM +0900, Joonsoo Kim wrote:
> On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
> > There have been a number of patch series posted designed to improve various
> > aspects of CMA. A sampling:
> > 
> > https://lkml.org/lkml/2014/10/15/623
> > http://marc.info/?l=linux-mm&m=141571797202006&w=2
> > https://lkml.org/lkml/2014/6/26/549
> > 
> > As far as I can tell, these are all trying to fix real problems with CMA but
> > none of them have moved forward very much from what I can tell. The goal of
> > this session would be to come out with an agreement on what are the biggest
> > problems with CMA and the best ways to solve them.
> 
> I also tried to solve problem from CMA, that is, reserved memory
> utilization.
> 
> https://lkml.org/lkml/2014/5/28/64
> 
> While playing that patchset, I found serious problem about free page
> counting, so I stopped to develop it for a while and tried to fix it.
> Now, it is fixed by me and I can continue my patchset.
> 
> https://lkml.org/lkml/2014/10/31/69
> 
> I heard that Minchan suggests new CMA zone like movable zone, and, I
> think that it would be the way to go. But, it would be a long-term goal
> and I'd like to solve utilization problem with my patchset for now.
> It is the biggest issue and it already forces someone to develop
> out of tree solution. It's not good that out of tree solution is used
> more and more in the product so I'd like to fix it quickly at first
> stage.
> 
> I think that CMA have big potential. If we fix problems of CMA
> completely, it can be used for many places. One such case in my mind
> is hugetlb or THP. Until now, hugetlb uses reserved approach, that is
> very inefficient. System administrator carefully set the number of
> reserved hugepage according to whole system workload. And application
> can't use it freely, because it is very limited and managed resource.
> If we use CMA for hugetlb, we can easily allocate hugepage and
> application can use hugepages more freely.
> 
> Anyway, I'd like to attend LSF/MM and discuss this topic.

I change the subject according to LSF/MM attend request format.
What I can do and why I'd like to attend is explained above.
Sorry for noise.

Thanks.

--
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>

[LSF/MM ATTEND] Improving CMA

[Gioh Kim]

>
>
> 2014-11-27 i??i?? 3:12i?? Joonsoo Kim i?'(e??) i?' e,?:
>> On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
>>> There have been a number of patch series posted designed to improve various
>>> aspects of CMA. A sampling:
>>>
>>> https://lkml.org/lkml/2014/10/15/623
>>> http://marc.info/?l=linux-mm&m=141571797202006&w=2
>>> https://lkml.org/lkml/2014/6/26/549
>>>
>>> As far as I can tell, these are all trying to fix real problems with CMA but
>>> none of them have moved forward very much from what I can tell. The goal of
>>> this session would be to come out with an agreement on what are the biggest
>>> problems with CMA and the best ways to solve them.
>>
>> I also tried to solve problem from CMA, that is, reserved memory
>> utilization.
>>
>> https://lkml.org/lkml/2014/5/28/64
>>
>> While playing that patchset, I found serious problem about free page
>> counting, so I stopped to develop it for a while and tried to fix it.
>> Now, it is fixed by me and I can continue my patchset.
>>
>> https://lkml.org/lkml/2014/10/31/69
>>
>> I heard that Minchan suggests new CMA zone like movable zone, and, I
>> think that it would be the way to go. But, it would be a long-term goal
>> and I'd like to solve utilization problem with my patchset for now.
>> It is the biggest issue and it already forces someone to develop
>> out of tree solution. It's not good that out of tree solution is used
>> more and more in the product so I'd like to fix it quickly at first
>> stage.
>>
>> I think that CMA have big potential. If we fix problems of CMA
>> completely, it can be used for many places. One such case in my mind
>> is hugetlb or THP. Until now, hugetlb uses reserved approach, that is
>> very inefficient. System administrator carefully set the number of
>> reserved hugepage according to whole system workload. And application
>> can't use it freely, because it is very limited and managed resource.
>> If we use CMA for hugetlb, we can easily allocate hugepage and
>> application can use hugepages more freely.
>>
>> Anyway, I'd like to attend LSF/MM and discuss this topic.
>>
>> Thanks.
>>
>
> Until now, I've used CMA with 2 out-of-tree patches:
> 1. https://lkml.org/lkml/2012/8/31/313 : Laura's patch
> 2. https://lkml.org/lkml/2014/5/28/64 : Joonsoo's patch
>
> And one merged patch by me: https://lkml.org/lkml/2014/9/4/78
>
> With them, my platform could've worked but it still had free-page-counting problem.
>
> I think if Joonsoo's patch [2] is merged into mainline, CMA can be stable and useful.
> Allocation latency Minchan mentioned is not problem for my platform.
> CMA allocation is not often and limited to only one drivers.
>
> Allocation guarantee is, I hope, fixed with my patch (https://lkml.org/lkml/2014/9/4/78) at least in my platform.
> My platform had worked for several hours but it lacks heavy load test.
> I have a plan to use CMA for massive product next year.
>
> I'd like to attend LSF/MM and discuss this topic too.

I'm sending LSF/MM attend request as Joonsoo did.
Thanks.

--
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: [Lsf-pc] [LSF/MM ATTEND] Improving CMA

[Jan Kara]

On Fri 28-11-14 16:13:27, Joonsoo Kim wrote:
> On Thu, Nov 27, 2014 at 03:12:04PM +0900, Joonsoo Kim wrote:
> > On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
> > > There have been a number of patch series posted designed to improve various
> > > aspects of CMA. A sampling:
> > > 
> > > https://lkml.org/lkml/2014/10/15/623
> > > http://marc.info/?l=linux-mm&m=141571797202006&w=2
> > > https://lkml.org/lkml/2014/6/26/549
> > > 
> > > As far as I can tell, these are all trying to fix real problems with CMA but
> > > none of them have moved forward very much from what I can tell. The goal of
> > > this session would be to come out with an agreement on what are the biggest
> > > problems with CMA and the best ways to solve them.
> > 
> > I also tried to solve problem from CMA, that is, reserved memory
> > utilization.
> > 
> > https://lkml.org/lkml/2014/5/28/64
> > 
> > While playing that patchset, I found serious problem about free page
> > counting, so I stopped to develop it for a while and tried to fix it.
> > Now, it is fixed by me and I can continue my patchset.
> > 
> > https://lkml.org/lkml/2014/10/31/69
> > 
> > I heard that Minchan suggests new CMA zone like movable zone, and, I
> > think that it would be the way to go. But, it would be a long-term goal
> > and I'd like to solve utilization problem with my patchset for now.
> > It is the biggest issue and it already forces someone to develop
> > out of tree solution. It's not good that out of tree solution is used
> > more and more in the product so I'd like to fix it quickly at first
> > stage.
> > 
> > I think that CMA have big potential. If we fix problems of CMA
> > completely, it can be used for many places. One such case in my mind
> > is hugetlb or THP. Until now, hugetlb uses reserved approach, that is
> > very inefficient. System administrator carefully set the number of
> > reserved hugepage according to whole system workload. And application
> > can't use it freely, because it is very limited and managed resource.
> > If we use CMA for hugetlb, we can easily allocate hugepage and
> > application can use hugepages more freely.
> > 
> > Anyway, I'd like to attend LSF/MM and discuss this topic.
> 
> I change the subject according to LSF/MM attend request format.
> What I can do and why I'd like to attend is explained above.
> Sorry for noise.
  Guys (both you and Gioh), is it such a big problem to write *new* email
(not just reply to an existing thread), use proper subject (you did this)
and write there: "I'm interested in CMA discussion, I also do X & Y". The
call for proposals specifically says "Please summarise what expertise you
will bring to the meeting". That helps us to select people when we have
more requests than space available.

I know it sounds like stupid ranting but it really makes it easier for
program committee to select people and pick up all the topic requests and
it will take you like 5 minutes max.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

--
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>

[Lsf-pc] [LSF/MM ATTEND] Improving CMA

[Gioh Kim]

I'm very sorry for causing noise.

I wanted to use CMA for 2 applications:
1. power saving: clear one ddr chip and turn off power
2. memory allocation for device: GPU and video and so on

At first I've tested CMA for power saving with 2 out-of-tree patches:
1. https://lkml.org/lkml/2012/8/31/313 : Laura's patch
2. https://lkml.org/lkml/2014/5/28/64 : Joonsoo's patch

I wanted to allocate the entire ddr chip, in contiguous physical address 0xXXXXXXXX ~ 0xXXXXXXXX
so that the allocation must not be failed.
But it often failed and I found superblocks of some filesystems pined pages for buffer-head.
Therefore I sumbitted a patch, https://lkml.org/lkml/2014/9/4/78.

With them, my platform could've worked for hours
but it still has free-page-counting problem and needs more heavy load test.

Allocation latency Minchan mentioned is not problem for my platform.
CMA allocation is not often and limited to only one drivers.

Allocation guarantee, Minchan menthined, is, my main concern.
I hope it is fixed partly with my patch (https://lkml.org/lkml/2014/9/4/78).

I have a plan to use CMA for massive product next year.
So I'd like to attend LSF/MM and discuss this topic.

Sorry for the wrong request again.

--
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: [Lsf-pc] [LSF/MM ATTEND] Improving CMA

[Joonsoo Kim]

On Fri, Nov 28, 2014 at 10:54:31AM +0100, Jan Kara wrote:
> On Fri 28-11-14 16:13:27, Joonsoo Kim wrote:
> > On Thu, Nov 27, 2014 at 03:12:04PM +0900, Joonsoo Kim wrote:
> > > On Mon, Nov 24, 2014 at 05:54:14PM -0800, Laura Abbott wrote:
> > > > There have been a number of patch series posted designed to improve various
> > > > aspects of CMA. A sampling:
> > > > 
> > > > https://lkml.org/lkml/2014/10/15/623
> > > > http://marc.info/?l=linux-mm&m=141571797202006&w=2
> > > > https://lkml.org/lkml/2014/6/26/549
> > > > 
> > > > As far as I can tell, these are all trying to fix real problems with CMA but
> > > > none of them have moved forward very much from what I can tell. The goal of
> > > > this session would be to come out with an agreement on what are the biggest
> > > > problems with CMA and the best ways to solve them.
> > > 
> > > I also tried to solve problem from CMA, that is, reserved memory
> > > utilization.
> > > 
> > > https://lkml.org/lkml/2014/5/28/64
> > > 
> > > While playing that patchset, I found serious problem about free page
> > > counting, so I stopped to develop it for a while and tried to fix it.
> > > Now, it is fixed by me and I can continue my patchset.
> > > 
> > > https://lkml.org/lkml/2014/10/31/69
> > > 
> > > I heard that Minchan suggests new CMA zone like movable zone, and, I
> > > think that it would be the way to go. But, it would be a long-term goal
> > > and I'd like to solve utilization problem with my patchset for now.
> > > It is the biggest issue and it already forces someone to develop
> > > out of tree solution. It's not good that out of tree solution is used
> > > more and more in the product so I'd like to fix it quickly at first
> > > stage.
> > > 
> > > I think that CMA have big potential. If we fix problems of CMA
> > > completely, it can be used for many places. One such case in my mind
> > > is hugetlb or THP. Until now, hugetlb uses reserved approach, that is
> > > very inefficient. System administrator carefully set the number of
> > > reserved hugepage according to whole system workload. And application
> > > can't use it freely, because it is very limited and managed resource.
> > > If we use CMA for hugetlb, we can easily allocate hugepage and
> > > application can use hugepages more freely.
> > > 
> > > Anyway, I'd like to attend LSF/MM and discuss this topic.
> > 
> > I change the subject according to LSF/MM attend request format.
> > What I can do and why I'd like to attend is explained above.
> > Sorry for noise.
>   Guys (both you and Gioh), is it such a big problem to write *new* email
> (not just reply to an existing thread), use proper subject (you did this)
> and write there: "I'm interested in CMA discussion, I also do X & Y". The
> call for proposals specifically says "Please summarise what expertise you
> will bring to the meeting". That helps us to select people when we have
> more requests than space available.
> 
> I know it sounds like stupid ranting but it really makes it easier for
> program committee to select people and pick up all the topic requests and
> it will take you like 5 minutes max.

Hello, Jan.

My bad.
I will write a new e-mail to lsf-pc with proper format and contents.
Again, sorry for noise.

Thanks.

--
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>