Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755191AbbFERm5 (ORCPT ); Fri, 5 Jun 2015 13:42:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41832 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754645AbbFERmz (ORCPT ); Fri, 5 Jun 2015 13:42:55 -0400 Message-ID: <5571DF9C.4030404@redhat.com> Date: Fri, 05 Jun 2015 10:42:52 -0700 From: Laura Abbott User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?TWljaGHFgiBOYXphcmV3aWN6?= CC: Weijie Yang , iamjoonsoo.kim@lge.com, Marek Szyprowski , Andrew Morton , Weijie Yang , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] cma: allow concurrent cma pages allocation for multi-cma areas References: <000001d09f66$056b67f0$104237d0$@yang@samsung.com> <5571BFBE.3070209@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2173 Lines: 53 On 06/05/2015 10:19 AM, Michał Nazarewicz wrote: > On Fri, Jun 05 2015, Laura Abbott wrote: >> On 06/05/2015 01:01 AM, Weijie Yang wrote: >>> Currently we have to hold the single cma_mutex when alloc cma pages, >>> it is ok when there is only one cma area in system. >>> However, when there are several cma areas, such as in our Android smart >>> phone, the single cma_mutex prevents concurrent cma page allocation. >>> >>> This patch removes the single cma_mutex and uses per-cma area alloc_lock, >>> this allows concurrent cma pages allocation for different cma areas while >>> protects access to the same pageblocks. >>> >>> Signed-off-by: Weijie Yang > >> Last I knew alloc_contig_range needed to be serialized which is why we >> still had the global CMA mutex. https://lkml.org/lkml/2014/2/18/462 >> >> So NAK unless something has changed to allow this. > > This patch should be fine. > > Change you’ve pointed to would get rid of any serialisation around > alloc_contig_range which is dangerous, but since CMA regions are > pageblock-aligned: > > /* > * Sanitise input arguments. > * Pages both ends in CMA area could be merged into adjacent unmovable > * migratetype page by page allocator's buddy algorithm. In the case, > * you couldn't get a contiguous memory, which is not what we want. > */ > alignment = max(alignment, > (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order)); > base = ALIGN(base, alignment); > size = ALIGN(size, alignment); > limit &= ~(alignment - 1); > > synchronising allocation in each area should work fine. > Okay yes, you are correct. I was somehow thinking that different CMA regions could end up in the same pageblock. This is documented in alloc_contig_range but can we put a comment explaining this here too? It seems to come up every time locking here is discussed. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/