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 9B5BFC27C4F for ; Thu, 13 Jun 2024 06:15:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 172FD6B009E; Thu, 13 Jun 2024 02:15:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 121D56B009F; Thu, 13 Jun 2024 02:15:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2B136B00A0; Thu, 13 Jun 2024 02:15:42 -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 D5E866B009E for ; Thu, 13 Jun 2024 02:15:42 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 882BDA0686 for ; Thu, 13 Jun 2024 06:15:42 +0000 (UTC) X-FDA: 82224854124.24.81403B8 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf09.hostedemail.com (Postfix) with ESMTP id C27D814000D for ; Thu, 13 Jun 2024 06:15:40 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718259339; 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=zRvrcjPhR+q8m9kx6xe/eWTFXA9VMLUn5sh24E/DBw0=; b=cdJGHluBWSt5m+3tjwhYgp6cheyKhAUye9IoS66gVDyuEdDnCvqxHEsC3292nsT/toRs3i la9j7lwobVE9A1g7QFs4ksB15Y8AG8vFyLLc/IwcrV/8pzJbvpmPZNeQQFfkXsrMKfNg0s mkuxQOG1aoByK2VAOAs/U/Z4g3gEDug= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718259339; a=rsa-sha256; cv=none; b=TvIZnmau51XK4TH9Acg3RaEzVl4L2PELpBIKPnRV8G3oSl/BrSJCcNiL332CdQOXQvSsrt j8EbrNO+smCSOgUuziAjipe8bnIBV0uBH5n6eKjoa2Eldh1z5vd+z4JN0bCZEkt67vEAxc Q432jkrIjGiJbxazsgrBAVDwtcZPkyU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-4ecf8213dc6so231641e0c.3 for ; Wed, 12 Jun 2024 23:15:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718259340; x=1718864140; 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=zRvrcjPhR+q8m9kx6xe/eWTFXA9VMLUn5sh24E/DBw0=; b=e2aZVV1RuKddKCtue9ouedYFklhgY1qal7bLLD8zI1fSc9GLt92N/Sl7ZafpMFvlNB horqC9IvcRbv5gKFhgwPMN+zLB6mgu+tkC3Nrstup6Ds9gBoy5FJZduP8xB30JzbszBN NnO+FtbyrquRvKkKauqaVxE9/uZvRetkIkmiXU3fdynrix2Jhif0zW2eVbAk+ieCAF6n z5x1e8nv3AxHWSG7dSGl7tm0GiqNNlNkVWSd3LtBOb90oxXncuLAZI3CzHiYjbozjiKn b4MRRkbJC8PEJungG6oW/18XKvKKeLhvHLJulNUW1+jPSDkJFH0A7La8ESL97wukXAw+ CzHg== X-Forwarded-Encrypted: i=1; AJvYcCUg7nLavGlrjCzZUOcqydAqLejyNKPwft/JEbUaJfqsLLX8Qz43D+JXW8Gln5ABhbubzzdpXPzEHuOmP+z2IR2sDQY= X-Gm-Message-State: AOJu0YygsaWm96yuKOhm0zNGozcljh5Sz2eAx02f8VaTfnFeGphI8GKX zlVvJPMKWtWSARQYGpEcV/YC3NHMIGy2J/lDIn+XqTY5M4njnMShraby6GbkF2ZGZlnvJ9X+Qqy Q0CE8eElBm8ldZCkfZBZkNlgpywo= X-Google-Smtp-Source: AGHT+IGIqmMCbiVe6uMn5U11DqIWVsuLRr+OsX5/SDqNPOf+pK1ldMb7w7imfdAuUXkVQnlu+dSPve3MemvK97R9vUI= X-Received: by 2002:a05:6122:21ac:b0:4bd:32c9:acb with SMTP id 71dfb90a1353d-4ed07b25702mr4771148e0c.7.1718259339547; Wed, 12 Jun 2024 23:15:39 -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 18:15:28 +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: rspam07 X-Rspamd-Queue-Id: C27D814000D X-Stat-Signature: 3t13mgg8swcmsikdcd4kf8y3o6osaq71 X-Rspam-User: X-HE-Tag: 1718259340-697340 X-HE-Meta: U2FsdGVkX1/0waGzllcVc0OGaImBdfI5IXC2gJlHuylsx0Yxgnu7cidtK0y2ECM0lq9LLLkUK2wvXc4hrKp6XOz/F0ABL5fKb4F6a0qa4quqZM9XymzUL2wiEdvWNcR4aJs1XIzgdEbYYtge8+siwM1lgNW8iil4xVPwE6y99OmeId09sFLIUQcB6vJNWx/WDnEYm8NIIqItC0VIpGx1Ard79s42ceeI4l6I1m3/odcaIdbmkpmEvMgMD+P2rME8hF+Fnaq1X1MpLVjzOB/SmrQZUVcTYToXp14DmDsQ4R6syxepESGru4NexRxDNuFnpJB48RuHQ0Sy/+fXoG6D2t6oxARN+t6RZZheOlNhhwjJfWHdIGdo0v4H6HggrKcDlNYOJxSCVKTlffMs5N40064Oxi15ReRfiqs/SM4HYhqA/OoRnojSsAGiwD4MqeiSCkh6Gtd3dApwIYOfTbvu4g4vvi2R/6eytGwrcg+84lX/vxX8GROXaiVV4iwJjQC905Lm5NL3fk6Wf7maeC1hTkoO7Ny61Y8Wbr1a/2HdFSa58XsjkiZrIil9f/CjMXitVDv+9qLoOJlgZuj7het8Tu9vXRHYVlxTuMhiWRhYr//SU87QZgfQPtucml6MgXXT+ELjRgP0V86T69vjqXkxzgmx4uTQq3FkptyKENGqdNPz8AAMAwkjxwdm6CUC1bIPmBzbvGzcdiEa99/vfoh6hQKwl5A+tT+pYxwkP1QdFi7eOTpzCXWchbWr6JKTtahorkQnu3Og2y3mSaj0UY5bQmD9YtGuSbfYrtLRITyUeG4wxPo1UHFuKwQScm7G4zY+3DIR1DKrnSq/qPf4FCxnUny8dFqPRTgG5aZfZrirvP/nQ8vCh+wAJ1i/BHyOlx4MvSedfz7/ifchfBHjccE09wE3LRLwthJPGnZYDquFiqCf7iBjID0lJM/KNrOzy2m2HBmJxEU4ECtB/BlLXvB ysyYeqWX iIra8baum0tEL8rPKKorAYncni/qMNy8StJJRbNV8vR+QfSNZtlGbrE2fYiIV5tk5lOig6wjCAzyHA0bdfeiGRGXkKMZZYlQqOQtvq5PzRZfEobc2cMDgBuQsgcWXh+p0r5XS9v8P+4GyQyob/2uGcyTjj4EYkSWtksIFVY5oRhkFTU7DmpCS9uWPhGkcv7iCHnI2q5bH8529dnnGpK9nX26h4aOJQpjg6agA2lYtWf4AQNfXz5p4na6a4aCLAew3hMN3PafSvBMcMWHz9pyY8dHXfZgsSsPo2xsfo2pqk44dywc38MleoD73ibcpJCYqVHjffVLAV78TqQGHAaVo4WUhFNNNmAOLZJnsru6MOUHWKAZrwfBfzMp9aIl2FW+Ggt2VyiuVMn2kVgQg+9+0Z6PBZs8Ii6mRLJJrdaN0zpPDCxs/EPaDqGN3a4aDACLuUwFOlBQdLqsmujvt1ahyAoTgX3aLD2r52O1a2SLCL6wbHtXv07/qhsoGdBfZGZ52ONNntNIAIcW3fNY3EhblSe42SLExtKPf3houx69sAfYOdp+hYyR02BASX2p8SrF9T2hjg3XzNXwnT1I= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, 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 5:32=E2=80=AFPM Zhai He wrote: > > > -----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 link= s or > > opening attachments. When in doubt, report the message using the 'Repor= t 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, report 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 headers? > > > > > 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 changed 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 misl= ead > > developers' > > > > > > judgment. > > > > > > > > I am not convinced that this patch is correct. If device-specific > > > > CMA is too small, why not increase it in the device tree? > > > > Conversely, if the default CMA size is too large, why not reduce it > > > > via the cmdline? CMA offers all kinds of flexible configuration op= tions 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 ha= s > > > > enough free space, yet someone fails to obtain contiguous memory fr= om it. > > > > > > > > This patch entirely negates the advantage we gain from device-speci= fic CMA. > > > > My point is that instead of modifying the core code, please conside= r > > > > correcting your device tree or cmdline configurations. > > > > > > > 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 the VPU. > > > > > > However, under our memory configuration, the device-specific CMA is n= ot > > enough to support the VPU decoding high-resolution code streams, so thi= s 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 require= s hardware protection, so its starting address cannot be specified arbitrar= ily. This causes the secure heap to occupy part of the default CMA, and the= default CMA is therefore reduced, so in order to avoid default CMA Shrinki= ng introduces other problems. We added a specific CMA area for the VPU. How= ever, due to the large size of the secure heap and default CMA, There is no= remaining memory available to increase specific CMA for VPU. I assume the secure heap you are referring to is a section of memory that should only be accessed by TrustZone and not be visible to Linux running in non-secure mode. How do you allocate this secure heap from the default CMA? 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? 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? > > > It seems you mean that only in some corner cases do you need a large CM= A, but > > most of the time, you don=E2=80=99t need it to be 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 allocat= ed by the driver is based on the video stream, we cannot determine the maxi= mum size of memory required by the VPU. This makes it impossible for us to = determine the size of the specific CMA assigned to the VPU. 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. I still don't understand your scenarios or the problem you are facing. Thanks Barry