From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by kanga.kvack.org (Postfix) with ESMTP id 4FCE76B0038 for ; Mon, 24 Nov 2014 20:54:17 -0500 (EST) Received: by mail-ie0-f181.google.com with SMTP id tp5so9771222ieb.26 for ; Mon, 24 Nov 2014 17:54:17 -0800 (PST) Received: from smtp.codeaurora.org (smtp.codeaurora.org. [198.145.11.231]) by mx.google.com with ESMTPS id c88si10734301iod.26.2014.11.24.17.54.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Nov 2014 17:54:16 -0800 (PST) Message-ID: <5473E146.7000503@codeaurora.org> Date: Mon, 24 Nov 2014 17:54:14 -0800 From: Laura Abbott MIME-Version: 1.0 Subject: [LSF/MM TOPIC] Improving CMA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Cc: zhuhui@xiaomi.com, minchan@kernel.org, iamjoonsoo.kim@lge.com, gioh.kim@lge.com, SeongJae Park 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by kanga.kvack.org (Postfix) with ESMTP id 733B96B0038 for ; Tue, 25 Nov 2014 06:32:35 -0500 (EST) Received: by mail-wi0-f173.google.com with SMTP id r20so8831610wiv.0 for ; Tue, 25 Nov 2014 03:32:35 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id dh10si15853923wib.80.2014.11.25.03.32.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 03:32:34 -0800 (PST) Date: Tue, 25 Nov 2014 11:32:26 +0000 From: Mel Gorman Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Improving CMA Message-ID: <20141125113225.GH2725@suse.de> References: <5473E146.7000503@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <5473E146.7000503@codeaurora.org> Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, SeongJae Park , minchan@kernel.org, zhuhui@xiaomi.com, iamjoonsoo.kim@lge.com, gioh.kim@lge.com 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by kanga.kvack.org (Postfix) with ESMTP id E28486B0069 for ; Tue, 25 Nov 2014 23:25:11 -0500 (EST) Received: by mail-pd0-f179.google.com with SMTP id w10so1974847pde.38 for ; Tue, 25 Nov 2014 20:25:11 -0800 (PST) Received: from lgeamrelo04.lge.com (lgeamrelo04.lge.com. [156.147.1.127]) by mx.google.com with ESMTP id w6si4838560pdp.190.2014.11.25.20.25.08 for ; Tue, 25 Nov 2014 20:25:10 -0800 (PST) Message-ID: <54755621.6050700@lge.com> Date: Wed, 26 Nov 2014 13:25:05 +0900 From: Gioh Kim MIME-Version: 1.0 Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Improving CMA References: <5473E146.7000503@codeaurora.org> <20141125113225.GH2725@suse.de> In-Reply-To: <20141125113225.GH2725@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman , Laura Abbott Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, SeongJae Park , minchan@kernel.org, zhuhui@xiaomi.com, iamjoonsoo.kim@lge.com 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by kanga.kvack.org (Postfix) with ESMTP id A18496B0069 for ; Wed, 26 Nov 2014 00:55:30 -0500 (EST) Received: by mail-pa0-f52.google.com with SMTP id eu11so2157583pac.39 for ; Tue, 25 Nov 2014 21:55:30 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com. [2607:f8b0:400e:c02::22e]) by mx.google.com with ESMTPS id xj9si5236927pab.73.2014.11.25.21.55.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 21:55:29 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id w10so2110516pde.19 for ; Tue, 25 Nov 2014 21:55:28 -0800 (PST) From: SeongJae Park Date: Wed, 26 Nov 2014 14:56:37 +0900 (KST) Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Improving CMA In-Reply-To: <54755621.6050700@lge.com> Message-ID: References: <5473E146.7000503@codeaurora.org> <20141125113225.GH2725@suse.de> <54755621.6050700@lge.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="781441777-2032870768-1416981410=:6720" Sender: owner-linux-mm@kvack.org List-ID: To: Gioh Kim Cc: Mel Gorman , Laura Abbott , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, SeongJae Park , minchan@kernel.org, zhuhui@xiaomi.com, iamjoonsoo.kim@lge.com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --781441777-2032870768-1416981410=:6720 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT 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. > --781441777-2032870768-1416981410=:6720-- -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by kanga.kvack.org (Postfix) with ESMTP id 7D00C6B006E for ; Wed, 26 Nov 2014 00:58:59 -0500 (EST) Received: by mail-pa0-f48.google.com with SMTP id rd3so2155971pab.35 for ; Tue, 25 Nov 2014 21:58:59 -0800 (PST) Received: from mx1.mxmail.xiaomi.com ([58.68.235.87]) by mx.google.com with ESMTP id qa5si5291252pbc.29.2014.11.25.21.58.54 for ; Tue, 25 Nov 2014 21:58:57 -0800 (PST) From: =?utf-8?B?5pyx6L6J?= Subject: =?utf-8?B?562U5aSNOiBbTHNmLXBjXSBbTFNGL01NIFRPUElDXSBJbXByb3ZpbmcgQ01B?= Date: Wed, 26 Nov 2014 05:58:51 +0000 Message-ID: <1416981530769.16741@xiaomi.com> References: <5473E146.7000503@codeaurora.org> <20141125113225.GH2725@suse.de>,<54755621.6050700@lge.com> In-Reply-To: <54755621.6050700@lge.com> Content-Language: zh-CN Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Gioh Kim , Mel Gorman , Laura Abbott Cc: "lsf-pc@lists.linux-foundation.org" , "linux-mm@kvack.org" , SeongJae Park , "minchan@kernel.org" , "iamjoonsoo.kim@lge.com" 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 -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by kanga.kvack.org (Postfix) with ESMTP id 14A0A6B0069 for ; Wed, 26 Nov 2014 01:46:21 -0500 (EST) Received: by mail-pa0-f49.google.com with SMTP id eu11so2232017pac.36 for ; Tue, 25 Nov 2014 22:46:20 -0800 (PST) Received: from lgeamrelo02.lge.com (lgeamrelo02.lge.com. [156.147.1.126]) by mx.google.com with ESMTP id bz3si5394686pbb.64.2014.11.25.22.46.18 for ; Tue, 25 Nov 2014 22:46:19 -0800 (PST) Date: Wed, 26 Nov 2014 15:46:20 +0900 From: Minchan Kim Subject: Re: [LSF/MM TOPIC] Improving CMA Message-ID: <20141126064620.GA10412@bbox> References: <5473E146.7000503@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5473E146.7000503@codeaurora.org> Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, zhuhui@xiaomi.com, iamjoonsoo.kim@lge.com, gioh.kim@lge.com, SeongJae Park 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: email@kvack.org -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) by kanga.kvack.org (Postfix) with ESMTP id 629116B0069 for ; Wed, 26 Nov 2014 13:29:47 -0500 (EST) Received: by mail-ig0-f177.google.com with SMTP id z20so3061445igj.10 for ; Wed, 26 Nov 2014 10:29:47 -0800 (PST) Received: from smtp.codeaurora.org (smtp.codeaurora.org. [198.145.11.231]) by mx.google.com with ESMTPS id ii1si3955862igb.19.2014.11.26.10.29.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Nov 2014 10:29:46 -0800 (PST) Message-ID: <54761C18.6090003@codeaurora.org> Date: Wed, 26 Nov 2014 10:29:44 -0800 From: Laura Abbott MIME-Version: 1.0 Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Improving CMA References: <5473E146.7000503@codeaurora.org> <20141125113225.GH2725@suse.de> <54755621.6050700@lge.com> In-Reply-To: <54755621.6050700@lge.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Gioh Kim , Mel Gorman Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, SeongJae Park , minchan@kernel.org, zhuhui@xiaomi.com, iamjoonsoo.kim@lge.com 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by kanga.kvack.org (Postfix) with ESMTP id DBA136B0069 for ; Thu, 27 Nov 2014 01:09:01 -0500 (EST) Received: by mail-pa0-f41.google.com with SMTP id rd3so4396585pab.0 for ; Wed, 26 Nov 2014 22:09:01 -0800 (PST) Received: from lgeamrelo01.lge.com (lgeamrelo01.lge.com. [156.147.1.125]) by mx.google.com with ESMTP id kv12si9870491pab.232.2014.11.26.22.08.58 for ; Wed, 26 Nov 2014 22:09:00 -0800 (PST) Date: Thu, 27 Nov 2014 15:12:04 +0900 From: Joonsoo Kim Subject: Re: [LSF/MM TOPIC] Improving CMA Message-ID: <20141127061204.GA6850@js1304-P5Q-DELUXE> References: <5473E146.7000503@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5473E146.7000503@codeaurora.org> Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, zhuhui@xiaomi.com, minchan@kernel.org, gioh.kim@lge.com, SeongJae Park , mgorman@suse.de 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by kanga.kvack.org (Postfix) with ESMTP id ADC326B0069 for ; Thu, 27 Nov 2014 02:43:13 -0500 (EST) Received: by mail-pa0-f49.google.com with SMTP id eu11so4481502pac.22 for ; Wed, 26 Nov 2014 23:43:13 -0800 (PST) Received: from lgemrelse7q.lge.com (LGEMRELSE7Q.lge.com. [156.147.1.151]) by mx.google.com with ESMTP id o10si10399109pby.25.2014.11.26.23.43.10 for ; Wed, 26 Nov 2014 23:43:12 -0800 (PST) Message-ID: <5476D60D.4030506@lge.com> Date: Thu, 27 Nov 2014 16:43:09 +0900 From: Gioh Kim MIME-Version: 1.0 Subject: Re: [LSF/MM TOPIC] Improving CMA References: <5473E146.7000503@codeaurora.org> <20141127061204.GA6850@js1304-P5Q-DELUXE> In-Reply-To: <20141127061204.GA6850@js1304-P5Q-DELUXE> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim , Laura Abbott Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, zhuhui@xiaomi.com, minchan@kernel.org, SeongJae Park , mgorman@suse.de 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by kanga.kvack.org (Postfix) with ESMTP id 30EE26B006E for ; Thu, 27 Nov 2014 03:16:50 -0500 (EST) Received: by mail-pd0-f177.google.com with SMTP id ft15so4437188pdb.22 for ; Thu, 27 Nov 2014 00:16:49 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com. [134.134.136.65]) by mx.google.com with ESMTP id fn1si10274809pbb.223.2014.11.27.00.16.47 for ; Thu, 27 Nov 2014 00:16:48 -0800 (PST) Date: Thu, 27 Nov 2014 15:56:25 +0800 From: Wanpeng Li Subject: Re: [LSF/MM TOPIC] Improving CMA Message-ID: <20141127075625.GA3317@kernel> Reply-To: Wanpeng Li References: <5473E146.7000503@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5473E146.7000503@codeaurora.org> Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, zhuhui@xiaomi.com, minchan@kernel.org, iamjoonsoo.kim@lge.com, gioh.kim@lge.com, SeongJae Park 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: email@kvack.org -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by kanga.kvack.org (Postfix) with ESMTP id 059DB6B0069 for ; Thu, 27 Nov 2014 11:11:21 -0500 (EST) Received: by mail-pd0-f172.google.com with SMTP id y13so5121345pdi.17 for ; Thu, 27 Nov 2014 08:11:20 -0800 (PST) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com. [66.63.167.143]) by mx.google.com with ESMTP id c10si11246148pdj.85.2014.11.27.08.11.17 for ; Thu, 27 Nov 2014 08:11:18 -0800 (PST) Message-ID: <1417104675.2202.16.camel@HansenPartnership.com> Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Improving CMA From: James Bottomley Date: Thu, 27 Nov 2014 08:11:15 -0800 In-Reply-To: <20141127075625.GA3317@kernel> References: <5473E146.7000503@codeaurora.org> <20141127075625.GA3317@kernel> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Wanpeng Li Cc: Laura Abbott , zhuhui@xiaomi.com, minchan@kernel.org, SeongJae Park , linux-mm@kvack.org, gioh.kim@lge.com, iamjoonsoo.kim@lge.com, lsf-pc@lists.linux-foundation.org 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by kanga.kvack.org (Postfix) with ESMTP id 742FA6B0069 for ; Fri, 28 Nov 2014 02:10:20 -0500 (EST) Received: by mail-pd0-f177.google.com with SMTP id ft15so6119703pdb.22 for ; Thu, 27 Nov 2014 23:10:20 -0800 (PST) Received: from lgemrelse6q.lge.com (LGEMRELSE6Q.lge.com. [156.147.1.121]) by mx.google.com with ESMTP id gx7si14714385pac.213.2014.11.27.23.10.17 for ; Thu, 27 Nov 2014 23:10:19 -0800 (PST) Date: Fri, 28 Nov 2014 16:13:27 +0900 From: Joonsoo Kim Subject: [LSF/MM ATTEND] Improving CMA Message-ID: <20141128071327.GB11802@js1304-P5Q-DELUXE> References: <5473E146.7000503@codeaurora.org> <20141127061204.GA6850@js1304-P5Q-DELUXE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141127061204.GA6850@js1304-P5Q-DELUXE> Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, zhuhui@xiaomi.com, minchan@kernel.org, gioh.kim@lge.com, SeongJae Park , mgorman@suse.de 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by kanga.kvack.org (Postfix) with ESMTP id 886BA6B0069 for ; Fri, 28 Nov 2014 02:15:40 -0500 (EST) Received: by mail-pd0-f174.google.com with SMTP id w10so6139851pde.19 for ; Thu, 27 Nov 2014 23:15:40 -0800 (PST) Received: from lgeamrelo04.lge.com (lgeamrelo04.lge.com. [156.147.1.127]) by mx.google.com with ESMTP id nr9si14941235pbc.1.2014.11.27.23.15.37 for ; Thu, 27 Nov 2014 23:15:39 -0800 (PST) Message-ID: <54782118.5040405@lge.com> Date: Fri, 28 Nov 2014 16:15:36 +0900 From: Gioh Kim MIME-Version: 1.0 Subject: [LSF/MM ATTEND] Improving CMA References: <5473E146.7000503@codeaurora.org> <20141127061204.GA6850@js1304-P5Q-DELUXE> <5476D60D.4030506@lge.com> In-Reply-To: <5476D60D.4030506@lge.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim , Laura Abbott Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, zhuhui@xiaomi.com, minchan@kernel.org, SeongJae Park , mgorman@suse.de > > > 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by kanga.kvack.org (Postfix) with ESMTP id 4DAD06B0069 for ; Fri, 28 Nov 2014 04:54:42 -0500 (EST) Received: by mail-wi0-f172.google.com with SMTP id n3so18031522wiv.5 for ; Fri, 28 Nov 2014 01:54:41 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id f9si20613251wie.14.2014.11.28.01.54.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Nov 2014 01:54:41 -0800 (PST) Date: Fri, 28 Nov 2014 10:54:31 +0100 From: Jan Kara Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Improving CMA Message-ID: <20141128095431.GB25991@quack.suse.cz> References: <5473E146.7000503@codeaurora.org> <20141127061204.GA6850@js1304-P5Q-DELUXE> <20141128071327.GB11802@js1304-P5Q-DELUXE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141128071327.GB11802@js1304-P5Q-DELUXE> Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim Cc: Laura Abbott , zhuhui@xiaomi.com, minchan@kernel.org, SeongJae Park , linux-mm@kvack.org, mgorman@suse.de, gioh.kim@lge.com, lsf-pc@lists.linux-foundation.org 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 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by kanga.kvack.org (Postfix) with ESMTP id 33C156B0069 for ; Sun, 30 Nov 2014 18:54:43 -0500 (EST) Received: by mail-pd0-f170.google.com with SMTP id fp1so9677104pdb.15 for ; Sun, 30 Nov 2014 15:54:42 -0800 (PST) Received: from lgemrelse6q.lge.com (LGEMRELSE6Q.lge.com. [156.147.1.121]) by mx.google.com with ESMTP id uh8si26253729pab.198.2014.11.30.15.54.40 for ; Sun, 30 Nov 2014 15:54:41 -0800 (PST) Message-ID: <547BAE3C.5020309@lge.com> Date: Mon, 01 Dec 2014 08:54:36 +0900 From: Gioh Kim MIME-Version: 1.0 Subject: [Lsf-pc] [LSF/MM ATTEND] Improving CMA References: <5473E146.7000503@codeaurora.org> <20141127061204.GA6850@js1304-P5Q-DELUXE> <20141128071327.GB11802@js1304-P5Q-DELUXE> In-Reply-To: <20141128071327.GB11802@js1304-P5Q-DELUXE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott , Jan Kara Cc: Joonsoo Kim , zhuhui@xiaomi.com, minchan@kernel.org, SeongJae Park , linux-mm@kvack.org, mgorman@suse.de, lsf-pc@lists.linux-foundation.org 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by kanga.kvack.org (Postfix) with ESMTP id 28AAC6B0069 for ; Mon, 1 Dec 2014 03:22:24 -0500 (EST) Received: by mail-pa0-f41.google.com with SMTP id rd3so10610050pab.14 for ; Mon, 01 Dec 2014 00:22:23 -0800 (PST) Received: from lgeamrelo04.lge.com (lgeamrelo04.lge.com. [156.147.1.127]) by mx.google.com with ESMTP id ll9si17576368pab.5.2014.12.01.00.22.21 for ; Mon, 01 Dec 2014 00:22:22 -0800 (PST) Date: Mon, 1 Dec 2014 17:25:41 +0900 From: Joonsoo Kim Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Improving CMA Message-ID: <20141201082541.GA2499@js1304-P5Q-DELUXE> References: <5473E146.7000503@codeaurora.org> <20141127061204.GA6850@js1304-P5Q-DELUXE> <20141128071327.GB11802@js1304-P5Q-DELUXE> <20141128095431.GB25991@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141128095431.GB25991@quack.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Jan Kara Cc: Laura Abbott , zhuhui@xiaomi.com, minchan@kernel.org, SeongJae Park , linux-mm@kvack.org, mgorman@suse.de, gioh.kim@lge.com, lsf-pc@lists.linux-foundation.org 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: email@kvack.org