Improving CMA

LSF/MM TOPIC Laura Abbott 10 participants 16 messages Nov 25, 2014 – Dec 1, 2014 Memory management

Share & tools

Laura Abbott

author

2014-11-25 01:54 UTC #0 lore raw

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

Signature · 9 lines

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 [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Mel Gorman

2014-11-25 11:32 UTC #1 lore raw

Quoted 12 lines · 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.

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.

Signature · 8 lines

Mel Gorman
SUSE Labs

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

Gioh Kim

2014-11-26 04:25 UTC #2 lore raw

2014-11-25 i??i?? 8:32i?? Mel Gorman i?'(e??) i?' e,?:

Quoted 14 lines · Laura Abbott

Quoted 12 lines
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.

Quoted 8 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

SeongJae Park

2014-11-26 05:55 UTC #3 lore raw

Hi Gioh,

Quoted 27 lines · Gioh Kim

2014-11-25 i??i?? 8:32i?? Mel Gorman i?'(e??) i?' e,?:
Quoted 14 lines · Laura Abbott
Quoted 12 lines
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.
Quoted 8 lines
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.

Quoted 3 lines

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().

Quoted 1 line

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

Quoted 5 lines

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.

朱辉

2014-11-26 05:58 UTC #4 lore raw

In reply to Gioh Kim

Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K5Y+R5Lu25Lq6OiBHaW9o IEtpbSA8Z2lvaC5raW1AbGdlLmNvbT4K5Y+R6YCB5pe26Ze0OiAyMDE05bm0MTHmnIgyNuaXpSAx MjoyNQrmlLbku7bkuro6IE1lbCBHb3JtYW47IExhdXJhIEFiYm90dArmioTpgIE6IGxzZi1wY0Bs aXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgbGludXgtbW1Aa3ZhY2sub3JnOyBTZW9uZ0phZSBQ YXJrOyBtaW5jaGFuQGtlcm5lbC5vcmc7IOacsei+iTsgaWFtam9vbnNvby5raW1AbGdlLmNvbQrk uLvpopg6IFJlOiBbTHNmLXBjXSBbTFNGL01NIFRPUElDXSBJbXByb3ZpbmcgQ01BCgoyMDE0LTEx LTI1IOyYpO2bhCA4OjMy7JeQIE1lbCBHb3JtYW4g7J20KOqwgCkg7JO0IOq4gDoKPiBPbiBNb24s IE5vdiAyNCwgMjAxNCBhdCAwNTo1NDoxNFBNIC0wODAwLCBMYXVyYSBBYmJvdHQgd3JvdGU6Cj4+ IFRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBwYXRjaCBzZXJpZXMgcG9zdGVkIGRlc2lnbmVk IHRvIGltcHJvdmUgdmFyaW91cwo+PiBhc3BlY3RzIG9mIENNQS4gQSBzYW1wbGluZzoKPj4KPj4g aHR0cHM6Ly9sa21sLm9yZy9sa21sLzIwMTQvMTAvMTUvNjIzCj4+IGh0dHA6Ly9tYXJjLmluZm8v P2w9bGludXgtbW0mbT0xNDE1NzE3OTcyMDIwMDYmdz0yCj4+IGh0dHBzOi8vbGttbC5vcmcvbGtt bC8yMDE0LzYvMjYvNTQ5Cj4+Cj4+IEFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGVzZSBhcmUgYWxs IHRyeWluZyB0byBmaXggcmVhbCBwcm9ibGVtcyB3aXRoIENNQSBidXQKPj4gbm9uZSBvZiB0aGVt IGhhdmUgbW92ZWQgZm9yd2FyZCB2ZXJ5IG11Y2ggZnJvbSB3aGF0IEkgY2FuIHRlbGwuIFRoZSBn b2FsIG9mCj4+IHRoaXMgc2Vzc2lvbiB3b3VsZCBiZSB0byBjb21lIG91dCB3aXRoIGFuIGFncmVl bWVudCBvbiB3aGF0IGFyZSB0aGUgYmlnZ2VzdAo+PiBwcm9ibGVtcyB3aXRoIENNQSBhbmQgdGhl IGJlc3Qgd2F5cyB0byBzb2x2ZSB0aGVtLgo+Pgo+Cj4gSSB0aGluayB0aGlzIGlzIGEgZ29vZCB0 b3BpYy4gU29tZSBvZiB0aGUgaXNzdWVzIGhhdmUgYmVlbiBicm91Z2h0IHVwIGJlZm9yZQo+IGF0 IExTRi9NTSBidXQgdGhleSBuZXZlciBtYWRlIHRoYXQgbXVjaCB0cmFjdGlvbiBzbyBpdCdzIHdv cnRoIHJldmlzaXRpbmcuIEkKPiBoYXZlbid0IGJlZW4gcGF5aW5nIGNsb3NlIGF0dGVudGlvbiB0 byB0aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb25zIGJ1dAo+IEkndmUgYmVlbiBhIGxpdHRsZSB3 b3JyaWVkIHRoYXQgdGhlIHBhZ2UgYWxsb2NhdG9yIHBhdGhzIGFyZSB0dXJuaW5nIGludG8KPiBh IGJpZ2dlciBhbmQgYmlnZ2VyIG1lc3MuIEknbSBhbHNvIGEgYml0IHdvcnJpZWQgdGhhdCBvcHRp b25zIHN1Y2ggYXMKPiBtaWdyYXRpbmcgcGFnZXMgb3V0IG9mIENNQSBhcmVhcyB0aGF0IGFyZSBh Ym91dCB0byBiZSBwaW5uZWQgZm9yIGhhdmluZwo+IGNhbGxiYWNrIG9wdGlvbnMgdG8gZm9yY2li bHkgZnJlZSBwYWdlcyBuZXZlciB3ZW50IGFueXdoZXJlLgo+Cgo+IEkgaGF2ZSB0d28gcXVlc3Rp b24uCj4KPiBGaXJzdCwgaXMgR0NNQSBhYmxlIHRvIHJlcGxhY2UgQ01BPyBJdCdzIG5ld3MgdG8g bWUuCj4gSSBuZWVkIHNvbWUgdGltZSB0byBjaGVjayBHQ01BLgo+Cj4gU2Vjb25kLCBpcyBDTUEg cG9wdWxhciBlbm91Z2ggdG8gY2hhbmdlIGFsbG9jYXRvciBwYXRoPwo+IFllcywgSSBuZWVkIGl0 Lgo+IEJ1dCBJIGRvbid0IGtub3cgYW55IGNvbXBhbnkgdXNlcyBpdCwgYW5kIG5vYm9keSBzZWVt cyB0byBoYXZlIGludGVyZXN0IGluCj4gaXQuCgpXZSAoeGlhb21pKSB1c2UgaXQgaW4gb3VyIG5l dyBtaWJveC4KClRoYW5rcywKSHVp

Laura Abbott

author

2014-11-26 18:29 UTC #5 lore raw

In reply to Gioh Kim

Quoted 27 lines · Gioh Kim

2014-11-25 i??i?? 8:32i?? Mel Gorman i?'(e??) i?' e,?:
Quoted 14 lines · Laura Abbott
Quoted 12 lines
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.
Quoted 8 lines
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.

Quoted 8 lines

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

Signature · 9 lines

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 [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Minchan Kim

2014-11-26 06:46 UTC #6 lore raw

In reply to Laura Abbott

Hello Laura,

Quoted 11 lines · 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 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.

Quoted 14 lines

Thanks,
Laura

Signature · 9 lines

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 [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Signature · 8 lines

Kind regards,
Minchan Kim

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

Joonsoo Kim

2014-11-27 06:09 UTC #7 lore raw

In reply to Laura Abbott

Quoted 11 lines · 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.

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.

Gioh Kim

2014-11-27 07:43 UTC #8 lore raw

2014-11-27 i??i?? 3:12i?? Joonsoo Kim i?'(e??) i?' e,?:

Quoted 41 lines · Laura Abbott

Quoted 11 lines
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.

Quoted 4 lines

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.

Gioh Kim

2014-11-28 07:15 UTC #9 lore raw

Quoted 62 lines

2014-11-27 i??i?? 3:12i?? Joonsoo Kim i?'(e??) i?' e,?:
Quoted 41 lines · Laura Abbott
Quoted 11 lines
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.
Quoted 4 lines
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.

Quoted 5 lines

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.

Joonsoo Kim

2014-11-28 07:10 UTC #10 lore raw

In reply to Joonsoo Kim

Quoted 41 lines · Joonsoo Kim

Quoted 11 lines · 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.
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.

Quoted 1 line

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.

Jan Kara

2014-11-28 09:54 UTC #11 lore raw

Quoted 42 lines · Joonsoo Kim

Quoted 41 lines · Joonsoo Kim
Quoted 11 lines · 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.
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.

Quoted 5 lines

Quoted 1 line
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

Signature · 8 lines

Jan Kara <[email protected]>
SUSE Labs, CR

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

Joonsoo Kim

2014-12-01 08:22 UTC #12 lore raw

Quoted 55 lines · Jan Kara

Quoted 42 lines · Joonsoo Kim
Quoted 41 lines · Joonsoo Kim
Quoted 11 lines · 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.
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.
Quoted 5 lines
Quoted 1 line
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.

Quoted 3 lines

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.

Gioh Kim

2014-11-30 23:54 UTC #13 lore raw

In reply to Joonsoo 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.

Wanpeng Li

2014-11-27 08:16 UTC #14 lore raw

In reply to Laura Abbott

Quoted 11 lines · 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.

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

Regards,
Wanpeng Li

Quoted 14 lines

Thanks,
Laura

Signature · 9 lines

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 [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

James Bottomley

2014-11-27 16:11 UTC #15 lore raw

Quoted 8 lines · Wanpeng Li

Quoted 7 lines · 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

Quoted 6 lines

Quoted 4 lines
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