From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753941AbbGaPJO (ORCPT ); Fri, 31 Jul 2015 11:09:14 -0400 Received: from mga09.intel.com ([134.134.136.24]:48163 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752754AbbGaPJM (ORCPT ); Fri, 31 Jul 2015 11:09:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,585,1432623600"; d="scan'208";a="533739959" Date: Fri, 31 Jul 2015 23:18:16 +0800 From: Feng Tang To: Michal Nazarewicz Cc: "linux-kernel@vger.kernel.org" , "m.szyprowski@samsung.com" , "kyungmin.park@samsung.com" , "akpm@linux-foundation.org" , "iamjoonsoo.kim@lge.com" Subject: Re: [PATCH] CMA: Don't return a valid cma for non-cma dev Message-ID: <20150731151816.GA18347@shbuild888> References: <1438223828-26140-1-git-send-email-feng.tang@intel.com> <1438311070.4299.1.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 31, 2015 at 02:05:17PM +0200, Michal Nazarewicz wrote: > On Fri, Jul 31 2015, Feng Tang wrote: > > Hi Michal Nazarewicz, > > > > Thanks for the review. > > > > On Thu, 2015-07-30 at 15:59 +0200, Michal Nazarewicz wrote: > >> On Thu, Jul 30 2015, Feng Tang wrote: > >> > When system(one x86 soc) boot, we saw many normal dma allocation requests > >> > goes to cma area. The call chain is > >> > dma_generic_alloc_coherent > >> > dma_alloc_from_contiguous -- arch/x86/kernel/pci-dma.c > >> > cma_alloc(dev_get_cma_area(dev), count, align) > >> > > >> > Current dev_get_cma_area() will return a valid "cma" anyway. Then all > >> > these requests will be taken as valid cma request, and get pages from > >> > cma area, which has 2 problems: > >> > 1. make the cma area fragmented > >> > 2. confuse the cma reservation, usually cma memory size is set according > >> > to the expectation of system scenario, these unexpected requests > >> > will affect the designed cma usage. > >> > > >> > So this patch will enforce the judgement, and only return valid "cma" > >> > for real cma user, thus make normal user like IO device driver not > >> > abuse cma reserved region. > >> > >> Just don’t set dma_contiguous_default_area. This patch defeats the > >> purpose of a *default* area. > > > > Yes! This is exactly what I tried when I first saw this problem, but > > this failed as there 2 places inside drivers/base/dma-contiguous.c > > which set the dma_contiguous_default_area > > > > 1) > > void __init dma_contiguous_reserve(phys_addr_t limit) > > { > > .... > > dma_contiguous_reserve_area(selected_size, selected_base, > > selected_limit, > > &dma_contiguous_default_area, > > fixed); > > .... > > } > > > > 2) > > static int __init rmem_cma_setup(struct reserved_mem *rmem) > > { > > ... > > if (of_get_flat_dt_prop(node, "linux,cma-default", NULL)) > > dma_contiguous_set_default(cma); > > ... > > } > > > > Are you suggesting me to remove them? > > Set CONFIG_CMA_SIZE_MBYTES to zero (in Kconfig) or add ‘cma=0’ on > command line, and don’t use ‘linux,cma-default’ in device tree. Then > you will end up with no default CMA area. Maybe I didn't make my problem clear, for our platform, we do need to use cma as we have camera ISP which has no IOMMU, so we cannot set "cma=0". The current situation is we have 2 kinds of request to call dma_alloc_from_contiguous(): 1. Those general IO drivers like spi/i2c/emmc/audio which will request 1 to dozen of pages for normal DMA use 2. The camera ISP and other HW which needs from seveal MB to 20MB CMA buffer, total CMA number may reach 180MB or more We don't want the 1st customers to go into CMA area, to fragment the CMA area from time to time. That's why I finally came up with this patch. Any suggestions? Thanks, Feng