Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753777AbcJZH1o (ORCPT ); Wed, 26 Oct 2016 03:27:44 -0400 Received: from mx2.suse.de ([195.135.220.15]:34593 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751810AbcJZH1n (ORCPT ); Wed, 26 Oct 2016 03:27:43 -0400 Subject: Re: [PATCH v6 3/6] mm/cma: populate ZONE_CMA To: Joonsoo Kim References: <1476414196-3514-1-git-send-email-iamjoonsoo.kim@lge.com> <1476414196-3514-4-git-send-email-iamjoonsoo.kim@lge.com> <33f0a8f3-38d1-e527-f71f-839afe0b2ed9@suse.cz> <20161018082730.GA20442@js1304-P5Q-DELUXE> <20161026043123.GA2901@js1304-P5Q-DELUXE> Cc: Andrew Morton , Rik van Riel , Johannes Weiner , mgorman@techsingularity.net, Laura Abbott , Minchan Kim , Marek Szyprowski , Michal Nazarewicz , "Aneesh Kumar K.V" , linux-mm@kvack.org, linux-kernel@vger.kernel.org From: Vlastimil Babka Message-ID: <49fde512-15dd-33dc-2120-a6ac1491a165@suse.cz> Date: Wed, 26 Oct 2016 09:27:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161026043123.GA2901@js1304-P5Q-DELUXE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2081 Lines: 42 On 10/26/2016 06:31 AM, Joonsoo Kim wrote: > Hello, > > Here comes fixed one. > > ----------->8------------ > From 93fb05a83d74f9e2c8caebc2fa6d1a8807c9ffb6 Mon Sep 17 00:00:00 2001 > From: Joonsoo Kim > Date: Thu, 24 Mar 2016 22:29:10 +0900 > Subject: [PATCH] mm/cma: populate ZONE_CMA > > Until now, reserved pages for CMA are managed in the ordinary zones > where page's pfn are belong to. This approach has numorous problems > and fixing them isn't easy. (It is mentioned on previous patch.) > To fix this situation, ZONE_CMA is introduced in previous patch, but, > not yet populated. This patch implement population of ZONE_CMA > by stealing reserved pages from the ordinary zones. > > Unlike previous implementation that kernel allocation request with > __GFP_MOVABLE could be serviced from CMA region, allocation request only > with GFP_HIGHUSER_MOVABLE can be serviced from CMA region in the new > approach. This is an inevitable design decision to use the zone > implementation because ZONE_CMA could contain highmem. Due to this > decision, ZONE_CMA will work like as ZONE_HIGHMEM or ZONE_MOVABLE. > > I don't think it would be a problem because most of file cache pages > and anonymous pages are requested with GFP_HIGHUSER_MOVABLE. It could > be proved by the fact that there are many systems with ZONE_HIGHMEM and > they work fine. Notable disadvantage is that we cannot use these pages > for blockdev file cache page, because it usually has __GFP_MOVABLE but > not __GFP_HIGHMEM and __GFP_USER. But, in this case, there is pros and > cons. In my experience, blockdev file cache pages are one of the top > reason that causes cma_alloc() to fail temporarily. So, we can get more > guarantee of cma_alloc() success by discarding that case. > > Implementation itself is very easy to understand. Steal when cma area is > initialized and recalculate various per zone stat/threshold. > > Reviewed-by: Aneesh Kumar K.V > Signed-off-by: Joonsoo Kim Acked-by: Vlastimil Babka