From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9EE5C4338F for ; Fri, 13 Aug 2021 10:08:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 57B9460F21 for ; Fri, 13 Aug 2021 10:08:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 57B9460F21 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BACA88D0001; Fri, 13 Aug 2021 06:08:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5D816B0071; Fri, 13 Aug 2021 06:08:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4B388D0001; Fri, 13 Aug 2021 06:08:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id 88AB66B006C for ; Fri, 13 Aug 2021 06:08:14 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3611718011ACC for ; Fri, 13 Aug 2021 10:08:14 +0000 (UTC) X-FDA: 78469632108.38.6087CAC Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf03.hostedemail.com (Postfix) with ESMTP id C18393004D45 for ; Fri, 13 Aug 2021 10:08:13 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 25477D6E; Fri, 13 Aug 2021 03:08:13 -0700 (PDT) Received: from [10.57.36.146] (unknown [10.57.36.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 57EFF3F70D; Fri, 13 Aug 2021 03:08:11 -0700 (PDT) Subject: =?UTF-8?B?UmU6IOWbnuWkjTog5Zue5aSNOiBbRXh0ZXJuYWxdUmU6IEFuIGNtYSBv?= =?UTF-8?Q?ptimization_patch_is_used_for_cma=5f=5balloc=7cfree=5d=2e?= To: Jichao Zou , David Hildenbrand , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "minchan@kernel.org" , "song.bao.hua@hisilicon.com" , "hch@lst.de" , "m.szyprowski@samsung.com" , "iommu@lists.linux-foundation.org" , JianQi Yang , Yanjune Tian References: From: Robin Murphy Message-ID: <52c0b1fd-d60f-5d7d-0b47-b3569678ebf6@arm.com> Date: Fri, 13 Aug 2021 11:08:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: C18393004D45 X-Stat-Signature: oqf9auywd59iyuj8ph6dw3k3sy39pcge Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf03.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com X-HE-Tag: 1628849293-542372 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2021-08-13 10:46, Jichao Zou wrote: > I got it, but in kernel that we used version, many heap drivers that in= drivers/dma-buf/ are based on CMA, not DMA carveout! > If this patch is not accepted, we cancel it!!! If you just want dma_alloc_coherent() to work automatically from a=20 carveout in the same manner as CMA, without having to stick=20 of_reserved_mem_device_init() calls everywhere to make drivers aware of=20 per-device carveouts, then [1] is probably what you want. If it's specifically dma-buf heaps that you're interested in, then=20 hacking the common CMA code to make the CMA heap behave like a carveout=20 heap is definitely the wrong approach - just implement a carveout heap=20 properly. It seems the only reason that hasn't ported over from ION is=20 that nobody's needed it yet[2]. Robin. [1] https://lore.kernel.org/linux-iommu/20210712061704.4162464-1-hch@lst.= de/ [2] https://lwn.net/Articles/801230/ >=20 > Thank you all. >=20 > Best Regards, >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Robin Murphy > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B48=E6=9C=8813=E6=97=A5= 17:16 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Jichao Zou ; David Hil= denbrand ; akpm@linux-foundation.org; linux-kernel@vger= .kernel.org; linux-mm@kvack.org; minchan@kernel.org; song.bao.hua@hisilic= on.com; hch@lst.de; m.szyprowski@samsung.com; iommu@lists.linux-foundatio= n.org; JianQi Yang ; Yanjune Tian > =E4=B8=BB=E9=A2=98: Re: =E5=9B=9E=E5=A4=8D: [External]Re: An cma optimi= zation patch is used for cma_[alloc|free]. >=20 > On 2021-08-13 09:27, Jichao Zou wrote: >> Hi David, >> I'll git-send-email patch again. >> Your understanding is exactly right. >> Let me explain the background of Patch, we are developing Android pho= ne, kernel is 5.10.43 LTS, we encounter cma_alloc failed during kernel st= artup, buddy system is ready, >> 01-11 14:22:08.650 216 216 E cma : cma_alloc([216][init]:cma(f= fffffff00b50000:total 8192) linux,cma(ffffffe89d084cf0), count 2, align 1= gfp_mask 0xcc0) >> 01-11 14:22:08.650 216 216 E cma : cma_alloc(): memory range a= t ffffffff00b62880 is busy, retrying >> =20 >> cma bitmap show memory is free, but alloc_contig_range failed, we che= cked it out that some drivers cma_alloc are >> "struct page *cma_alloc(struct cma *cma, size_t count, unsigned int a= lign, bool no_warn)" >> In 5.10.43, cma_alloc is >> "struct page *cma_alloc(struct cma *cma, size_t count, unsigned int a= lign, gfp_t gfp_mask)" >> After change cma_alloc parameter with GFP_KERNEL, issue is fixed, = at the same time, we found that preallocate a portion of cma memory for a= udio&video resulted in better performance and guarantee AV function even = under memory pressure, so we try to submit this patch. >=20 > The whole point of CMA is that the memory can be shared by moveable pag= es while it's not being used for DMA. If you want a dedicated DMA carveou= t, there are already mechanisms for that. >=20 > Robin. >=20 >> >> Thanks. >> >> Best Regards, >> >> Zou Jichao =E9=82=B9=E7=BA=AA=E8=B6=85 >> Advisory Engineer, SW BSP >> MBG ROW SW BJ PF BSP (CN) >> Motorola Mobility, A Lenovo Company >> motorola.com >> M +86 18910860212 >> E zoujc@lenovo.com >> twitter | facebook | instagram | blog | forums >> >> >> >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: David Hildenbrand >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B48=E6=9C=8813=E6=97=A5= 15:45 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Jichao Zou ; akpm@lin= ux-foundation.org; >> linux-kernel@vger.kernel.org; linux-mm@kvack.org; minchan@kernel.org; >> song.bao.hua@hisilicon.com; hch@lst.de; m.szyprowski@samsung.com; >> robin.murphy@arm.com; iommu@lists.linux-foundation.org; JianQi Yang >> ; Yanjune Tian >> =E4=B8=BB=E9=A2=98: [External]Re: An cma optimization patch is used fo= r cma_[alloc|free]. >> >> On 13.08.21 09:00, Jichao Zou wrote: >>> Pre-allocate=C2=A0CMA=C2=A0memory=C2=A0that=C2=A0configured=C2=A0in=C2= =A0device tree,=C2=A0this=C2=A0greatly >>> improves=C2=A0the=C2=A0CMA=C2=A0memory allocation=C2=A0efficiency,=C2= =A0cma_[alloc|free]=C2=A0is >>> less than=C2=A01ms,=C2=A0old=C2=A0way=C2=A0is=C2=A0took=C2=A0a=C2=A0f= ew=C2=A0ms=C2=A0to=C2=A0tens=C2=A0or hundreds=C2=A0ms. >>> >> >> Please send patches as proper emails (man git-format-patch; man git-se= nd-email). >> >> What you propose is turning cma reservations into something comparable= to permanent boottime allocations. From the POV of the buddy, the pages = are always allocated and cannot be repurposed for e.g., movable allocatio= ns until *actually* allocated via CMA. >> >> I don't think we want this behavior upstream. >> >> -- >> Thanks, >> >> David / dhildenb >>