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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E1A3C27C75 for ; Thu, 13 Jun 2024 09:44:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A29BF6B009E; Thu, 13 Jun 2024 05:44:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D9636B00A6; Thu, 13 Jun 2024 05:44:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 879D66B00A7; Thu, 13 Jun 2024 05:44:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 657356B009E for ; Thu, 13 Jun 2024 05:44:03 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CA5B440816 for ; Thu, 13 Jun 2024 09:44:02 +0000 (UTC) X-FDA: 82225379124.02.2539ACB Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) by imf09.hostedemail.com (Postfix) with ESMTP id 02ED914000A for ; Thu, 13 Jun 2024 09:44:00 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718271840; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fGZpwvvFWoUM4hVcXQNXUXevJ3SayuXE1Zat2o0h0YY=; b=Bw6p6HXj92frNrA+vcZWLvYKpAT0vOiBWMo/c0XxxUuZ3wioEHBqFQmwr3E/UeJpKEb+4T 3KxRp/9KHNBzfDhIKy1yDJFT7KpgBtXBgPIyBsYNxJXXXuHddNr8/lZtVjNqw4ljuPs3we bU+DJCJopBsLkmU05rin/isBWNdkpk0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718271840; a=rsa-sha256; cv=none; b=XZyBOyPkzH/BZErg/2lOOqYULZju9geq3WUOWwIWQL2J1U2xKUD4lZWJEjGJh5ThO7oH6/ dam0Dgc2AuBALnynSoKrrUl48mUwU+xq211Qa2DxqqpJz5unvlg2ZP/JXzz5pjVpbNq+Oz 8JF82iJcuq/Nl5wSo8um6Lb49v0GHlU= Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-4e93a260becso267512e0c.1 for ; Thu, 13 Jun 2024 02:44:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718271840; x=1718876640; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fGZpwvvFWoUM4hVcXQNXUXevJ3SayuXE1Zat2o0h0YY=; b=eP3gsKEX2nKlRxeIZjulfZHrP0XRGA9fWLJ9IlauCQoPWCs7tXGZH65LspQx4k8KYd PUMzZYJQZr/aceDb8CHA21cS/x7UbgRfsKduhDRxLEGv0vxu8YGr23tjVJEmD93xQGR7 r9vg5WevxUk/C6frHmPEAt3AxRj4V0zDLZA3WEJYh2le1I7C4xPE/iDxrL8I1lZszuGt WeQkmYSiShll86uE2SnfGESx4/lfypvI98erbT+wqi4gjS9pCVwyKhfEJ8FqaS6vhfuu RQ2a/xTHgmILPKkudNA6PKajrH9T1MxZjeeN1VmyzoP9tkQ6fO694AXRMuFZpZuX1DJp Evew== X-Forwarded-Encrypted: i=1; AJvYcCUiuUm/IOSw23KF0VoQuONXDtdI78IQ98FeWD1G3DMDburRBLhwiv7BMdK0b20MwHQAZK+GSTu/Z/h945aOYO4NgfM= X-Gm-Message-State: AOJu0YxNxU0HYJUI3Ogw3jWs1BIGxn33O19jVm8kvP8zhrDQGsuOrzrK q3F7OaAeJCxRi4Ly5p8whWe74iAVRO1a79nHHb/Y4Qk5yMy6uisQgjHbSi9yr4RO301G5DOSLgG ksYESVMtyXnZbXnFhNMcn0eztYFs= X-Google-Smtp-Source: AGHT+IGzVboPNn9QwP00HuEIScFGw9jAyxyp7d/HTvGYqatEmQgQOs87kiAZnvyqZ+VNoxlfAX7WDSMTcRpcUVhu3AU= X-Received: by 2002:a05:6122:6107:b0:4ed:145:348f with SMTP id 71dfb90a1353d-4ed07b90d72mr3768649e0c.12.1718271839964; Thu, 13 Jun 2024 02:43:59 -0700 (PDT) MIME-Version: 1.0 References: <20240612081216.1319089-1-zhai.he@nxp.com> <20240612114748.bf5983b50634f23d674bc749@linux-foundation.org> In-Reply-To: From: Barry Song Date: Thu, 13 Jun 2024 21:43:48 +1200 Message-ID: Subject: Re: [EXT] Re: [PATCH v2] Supports to use the default CMA when the device-specified CMA memory is not enough. To: Zhai He Cc: Andrew Morton , "sboyd@kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Zhipeng Wang , Jindong Yue , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 02ED914000A X-Stat-Signature: 19ot34azbcq7oa187id3kt4rjebnitgs X-HE-Tag: 1718271840-217754 X-HE-Meta: U2FsdGVkX1/T4aYLX/T0rBVPqHF8cfIyM5OetkfLLZBVUUimc5o7oVeFYjklZOonowV5VKD/GBhtilXRn2hWMGtKdCqTiMHUH8zKQGQV7xu5JuQwGmWj3TeAnK8FhVp5FgZmGRdaBfyZh0+0nqYVmW0NcJ0MFlgAP45edYrO1EZINj4cNYZ/lOsPbEKwSshz81Jsfr0+C4Jc4+Tb5ikDWW5iFgDM/2zT8bDADTGKplR+1dhg7DXUQI0O6x92ThoUxE5gmL0laWcC/zo1pqHOnGzV7QuvGRvRL2if37Aw9Ze53izpglke2L7hj+P7EP3WsL2OWvwnATr50zDqADC93ubxHmquLfGebwfo+qgFjVEgdocgdy1AuAXzT2QwnXIr/6sDoXjDrebfYKnPqF6PyWidOLMysw0LV6jatRrYoJvuVcSIjsiP0s0fceciRZ1v6dWLG5Cu+SGxc+GXNanzcsF4kIduJIQ5m8ta22nIegyxDjXn5pYqes2vnCadw2LD7bq7xSYXLcD4uBVxRWnUE4zKArgubwnp5DiuSGch/wN7zBAQeukDHJAUySXD97RIAabbUJj4H11KgWi+W1XN2CFqUS0jKhqw2ZiPFY08PtGwAtX8VLYiU8AT3hHlYgllVfKRfBqA8WS1TvpuT6LoNduWVB0+DvcJGNoaP6vrSNtDLoMRY77mp2IZKmN65A6YDPol1XqoLVwc6do5DZQHL2haHzUSOtLSmD8p1W2ysrGiWZHwuvfo8kMeKTlUhCJ39vcHudGDpLduQ4PQspM4Vhvjo2ZJKS2KlM6fsnDsscbhDTh/fwTPWKYlQoMQaCyqa/+H2eYl1Tavu0V4uAio29m1/yY/tO1fPiC4rWa/LiMRL1Jta9OSfi4eTDGdUAVDjE+fO0mUqyCiZ/V+ncEFTlsXXlnJUyt1bxJEeaxwnTXgTMjdiaewDVeCfqD50iEADWbcs9Tptc9WK43J38h ZeXNR1ek KFcdEq9bFj7uRtflHyO/Z7+iXVeafmkI6NFlsZhoIdTX1WGNWA63WWE3+0o4tsle+1DjEz+29MWF3yH1uuQoRFHt9b/730wacnoP9Wqu95SLTJ0aBtkpJNL1uyZ0T9JO1AztJMoAAoQvL0zV1C5NvREgCGExA4r5tYAF/2HRF/VDlq4eEg2pFj0jTtlwfJjio8Ta5xPkrDTKEPLVUxmMrxncQ5CwdiBKaG28wHbedXbAas19MLatbsY8ntZsgzp2hbjKeP3vOFYeACqvLDFUxB8Z5HU5CUUuKjGqZLPCfVrioNY1nRYWhZHPMqfUNHs6fmQwziJPuW/TnJdBNBi1NQ/tfpA9JEyLXD0aab39BYkwJbSh4k0xJJdO0L2Xgv602HaXhN8BbXawDg5N78gjuAoOUA+fAvLFTVC/MXrurCV7irj3UmsMSYvJGf2PQ1VOOkF9VJotFlrUADaJupYmzjXKwfpqGmCbnyrZ61iT1c7v8f1otvTeMiPczSBWLsEvpSeK6e6DFAUa+yP6/9k2E0+j/o9IYWJrQ0KkoJBUC2f3HWYSrnFlxTM5x0IQlPWSShCvVDhpmZIUZVGw= 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: List-Subscribe: List-Unsubscribe: On Thu, Jun 13, 2024 at 8:49=E2=80=AFPM Zhai He wrote: > > > -----Original Message----- > > From: Barry Song > > Sent: Thursday, June 13, 2024 3:38 PM > > To: Zhai He > > Cc: Andrew Morton ; sboyd@kernel.org; > > linux-mm@kvack.org; linux-kernel@vger.kernel.org; Zhipeng Wang > > ; Jindong Yue ; Christoph > > Hellwig > > Subject: Re: [EXT] Re: [PATCH v2] Supports to use the default CMA when = the > > device-specified CMA memory is not enough. > > > > Caution: This is an external email. Please take care when clicking link= s or > > opening attachments. When in doubt, report the message using the 'Repor= t this > > email' button > > > > > > On Thu, Jun 13, 2024 at 7:11=E2=80=AFPM Zhai He wrote= : > > > > > > > -----Original Message----- > > > > From: Barry Song > > > > Sent: Thursday, June 13, 2024 2:15 PM > > > > To: Zhai He > > > > Cc: Andrew Morton ; sboyd@kernel.org; > > > > linux-mm@kvack.org; linux-kernel@vger.kernel.org; Zhipeng Wang > > > > ; Jindong Yue ; > > > > Christoph Hellwig > > > > Subject: Re: [EXT] Re: [PATCH v2] Supports to use the default CMA > > > > when the device-specified CMA memory is not enough. > > > > > > > > Caution: This is an external email. Please take care when clicking > > > > links or opening attachments. When in doubt, report the message > > > > using the 'Report this email' button > > > > > > > > > > > > On Thu, Jun 13, 2024 at 5:32=E2=80=AFPM Zhai He w= rote: > > > > > > > > > > > -----Original Message----- > > > > > > From: Barry Song > > > > > > Sent: Thursday, June 13, 2024 11:28 AM > > > > > > To: Zhai He > > > > > > Cc: Andrew Morton ; sboyd@kernel.org= ; > > > > > > linux-mm@kvack.org; linux-kernel@vger.kernel.org; Zhipeng Wang > > > > > > ; Jindong Yue ; > > > > > > Christoph Hellwig > > > > > > Subject: Re: [EXT] Re: [PATCH v2] Supports to use the default > > > > > > CMA when the device-specified CMA memory is not enough. > > > > > > > > > > > > Caution: This is an external email. Please take care when > > > > > > clicking links or opening attachments. When in doubt, report th= e > > > > > > message using the 'Report this email' button > > > > > > > > > > > > > > > > > > On Thu, Jun 13, 2024 at 2:34=E2=80=AFPM Zhai He wrote: > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Barry Song > > > > > > > > Sent: Thursday, June 13, 2024 5:37 AM > > > > > > > > To: Andrew Morton > > > > > > > > Cc: Zhai He ; sboyd@kernel.org; > > > > > > > > linux-mm@kvack.org; linux-kernel@vger.kernel.org; > > > > > > > > stable@vger.kernel.org; Zhipeng Wang > > > > > > > > ; Jindong Yue = ; > > > > > > > > Christoph Hellwig > > > > > > > > Subject: [EXT] Re: [PATCH v2] Supports to use the default > > > > > > > > CMA when the device-specified CMA memory is not enough. > > > > > > > > > > > > > > > > Caution: This is an external email. Please take care when > > > > > > > > clicking links or opening attachments. When in doubt, repor= t > > > > > > > > the message using the 'Report this email' button > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 13, 2024 at 6:47=E2=80=AFAM Andrew Morton > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, 12 Jun 2024 16:12:16 +0800 "zhai.he" > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > From: He Zhai > > > > > > > > > > > > > > > > > > (cc Barry & Christoph) > > > > > > > > > > > > > > > > > > What was your reason for adding cc:stable to the email he= aders? > > > > > > > > > Does this address some serious problem? If so, please > > > > > > > > > fully describe that problem. > > > > > > > > > > > > > > > > > > > In the current code logic, if the device-specified CMA > > > > > > > > > > memory allocation fails, memory will not be allocated > > > > > > > > > > from the > > > > default CMA area. > > > > > > > > > > This patch will use the default cma region when the > > > > > > > > > > device's specified CMA is not enough. > > > > > > > > > > > > > > > > > > > > In addition, the log level of allocation failure is cha= nged to debug. > > > > > > > > > > Because these logs will be printed when memory > > > > > > > > > > allocation from the device specified CMA fails, but if > > > > > > > > > > the allocation fails, it will be allocated from the > > > > > > > > > > default cma area. It can easily mislead > > > > > > developers' > > > > > > > > > > judgment. > > > > > > > > > > > > > > > > I am not convinced that this patch is correct. If > > > > > > > > device-specific CMA is too small, why not increase it in th= e device > > tree? > > > > > > > > Conversely, if the default CMA size is too large, why not > > > > > > > > reduce it via the cmdline? CMA offers all kinds of flexibl= e > > > > > > > > configuration options based > > > > > > on users=E2=80=99 needs. > > > > > > > > > > > > > > > > One significant benefit of device-specific CMA is that it > > > > > > > > helps decrease fragmentation in the common CMA pool. While > > > > > > > > many devices allocate memory from the same pool, they have > > > > > > > > different memory requirements in terms of sizes and > > > > > > > > alignments. Occasions of memory allocation and release can > > > > > > > > lead to situations where the CMA pool has enough free space= , > > > > > > > > yet someone fails to obtain > > > > contiguous memory from it. > > > > > > > > > > > > > > > > This patch entirely negates the advantage we gain from > > > > > > > > device-specific > > > > CMA. > > > > > > > > My point is that instead of modifying the core code, please > > > > > > > > consider correcting your device tree or cmdline configurati= ons. > > > > > > > > > > > > > > > Because we enabled secure heap to support widevine DRM, and > > > > > > > secure heap requires security configuration, its starting > > > > > > > address cannot be specified arbitrarily, which causes the > > > > > > > default CMA to be reduced. So we > > > > > > reduced the CMA, but in order to avoid the impact of reducing > > > > > > the CMA, we used a multi-segment CMA and gave one segment to th= e > > VPU. > > > > > > > > > > > > > > However, under our memory configuration, the device-specific > > > > > > > CMA is not > > > > > > enough to support the VPU decoding high-resolution code streams= , > > > > > > so this patch is added so that the VPU can work properly. > > > > > > > Thanks. > > > > > > > > > > > > I don=E2=80=99t quite understand what you are saying. Why can= =E2=80=99t you > > > > > > increase VPU=E2=80=99s CMA size? > > > > > Thanks for your quick reply. > > > > > Because we added a secure heap to support Widevine DRM, this heap > > > > requires hardware protection, so its starting address cannot be > > > > specified arbitrarily. This causes the secure heap to occupy part o= f > > > > the default CMA, and the default CMA is therefore reduced, so in > > > > order to avoid default CMA Shrinking introduces other problems. We > > > > added a specific CMA area for the VPU. However, due to the large > > > > size of the secure heap and default CMA, There is no remaining memo= ry > > available to increase specific CMA for VPU. > > > > > > > > I assume the secure heap you are referring to is a section of memor= y > > > > that should only be accessed by TrustZone and not be visible to > > > > Linux running in non-secure mode. How do you allocate this secure h= eap > > from the default CMA? > > > > > > No, secure heap is a reserved memory, secure heap is not allocated fr= om CMA, > > secure heap has been reserved during the kernel startup phase. > > > And this reserved memory is protected by hardware. Only specific hard= ware > > and secure world can accessed it. > > > For example: > > > &{/reserved-memory/} { > > > secure_region: secure { > > > compatible =3D "imx-secure-ion-pool"; > > > reg =3D <0x0 0xA0000000 0 0x1EF00000>; > > > }; > > > }; > > > > > > > Do you use the cma_alloc() APIs or the dma_alloc_coherent() APIs? > > > > Given that the VPU has its own device-specific CMA, why is this > > > > secure heap allocated from the default CMA instead of the VPU's CMA= ? > > > > > > > The VPU driver will use dma_alloc_coherent() to allocate contiguous m= emory. > > The secure heap is not allocated from the CMA, but because the secure h= eap is > > enabled, it occupies some contiguous memory, causing the default CMA to= be > > reduced. > > > > > > > If this secure heap was allocated before the kernel booted, why did > > > > the kernel(your dts) fail to mark this area as nomap/reserved to > > > > prevent the default CMA from intersecting with it? > > > > > > > Secure heap does not intersect with the CMA. > > > for example: > > > before secure heap enabled: > > > 0xA000 0000 ~ 0xFFFFFFFF: default CMA > > > after secure heap enabled: > > > 0x9000 0000 ~0x9FFF FFFF is the CMA specified by VPU, > > > 0xA000 0000 ~0xAFFF FFFF is secure heap, (the start address cannot be > > specified arbitrarily, because this memory is protected by hardware, if= the start > > address is 0x9000 0000, uboot will use this memory, but uboot can't acc= ess this > > memory because of hardware protection. So we find a section of memory t= hat > > UBOOT will not use as secure heap. > > > Note: The memory of uboot can be adjusted, but avoiding the secure > > > heap will limit the memory range that uboot can use, causing problems > > > such as the uboot stack) > > > 0xB000 0000 ~0xFFFFFFFF is default CMA. > > > So default CMA is reduced. > > > > How is that related to your patch? I assume the default CMA is reduced = because > > you modified it in the DTS after enabling the secure heap, as the CMA s= ize is set > > by you. The default CMA size won't automatically decrease due to the se= cure > > heap. To me, 0xB0000000-0xFFFFFFFF(1.25GiB) is still too large a CMA. > > > > Sorry, This example is just an example. In fact, the size of our default = CMA is less than 1.25GiB. > Our current memory distribution is as follows. Now the size of "c" (defau= lt CMA) could not meet the needs of our requirement. And "b" (reserved memo= ry for secure) is fixed, so we couldn't expand "c" (default CMA) through mo= dify DTS. Then we reserved "a" (specific CMA) for VPU. However, we have con= firmed with the multimedia team that the maximum size required is It is unc= ertain, so specify "a" for VPU to use first, and "c" for other devices that= require continuous memory. If "a" is not enough, use "c". > That's the purpose of this patch. > -------------------------------------------------- > | a. VPU specific cma | > -------------------------------------------------- > | b. reserved memory for secure | > --------------------------------------------------- > | c. default CMA | > --------------------------------------------------- > > > Ok, I understand your problem. Because B is enabled, you can't have C as la= rge as you would without B. So you add A, but A might have insufficient space f= or high-resolution video. You also don't know the exact size needed for A. In = the corner case of encoding/decoding high-resolution video, A might be insuffic= ient, forcing you to borrow memory from C. Because B is situated between A and C= , creating a gap, you cannot merge A and C into a single default CMA. This does indeed seem like a valid requirement. Please ensure to clearly describe the problem next time. However, as a general rule, allowing device-specific= CMAs to borrow from the default CMA is not advisable. This would undermine the reasons why we started supporting device-specific CMAs in the first place. So the problem is that memory holes may prevent the formation of large CMAs= . This situation raises a question: can we have two or more default CMAs due = to memory holes like B, which might hinder the system from obtaining a suffici= ently large default CMA? If you could define both A and C as default CMAs, you wouldn't require these kinds of fallbacks. Is it possible for you to make dma_contiguous_default_area a list rather than a global variant ? Another option is that we allow devices to have more than one memory-region= , we can use device tree to fallback. memory-region =3D <&mem1, &mem2>; My perspective is that I acknowledge your problem as a valid requirement. However, I find the approach to be too aggressive. > > > > > > > > > > > It seems you mean that only in some corner cases do you need a > > > > > > large CMA, but most of the time, you don=E2=80=99t need it to b= e this > > > > > > big? So you have > > > > to "borrow" > > > > > > memory from the > > > > > > default CMA. but why not move that portion from the default CMA > > > > > > to your VPU=E2=80=99s CMA? > > > > > > > > > > > This is a method, but because for VPU, the continuous memory size > > > > > allocated > > > > by the driver is based on the video stream, we cannot determine the > > > > maximum size of memory required by the VPU. This makes it impossibl= e > > > > for us to determine the size of the specific CMA assigned to the VP= U. Thanks. > > > > > > > > I don't understand how this can happen. You should precisely know > > > > the maximum size required for the VPU based on your multimedia > > > > pipeline and resolutions. > > > > > > > We cannot estimate the maximum contiguous memory required by the VPU > > because it depends on how the video is encoded. > > > Thanks very much. > > > > Yes, you can. Please ask your multimedia team; they will give you a num= ber. > > > > > > > > > I still don't understand your scenarios or the problem you are faci= ng. > > > > > > > > Thanks Barry