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 2560DC27C6E for ; Thu, 13 Jun 2024 03:28:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FB416B00A1; Wed, 12 Jun 2024 23:28:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 584316B00A3; Wed, 12 Jun 2024 23:28:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FE686B00A5; Wed, 12 Jun 2024 23:28:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1B1806B00A1 for ; Wed, 12 Jun 2024 23:28:42 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CD5A61C07A7 for ; Thu, 13 Jun 2024 03:28:41 +0000 (UTC) X-FDA: 82224433242.20.FE8CA1A Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) by imf01.hostedemail.com (Postfix) with ESMTP id 25CFA40004 for ; Thu, 13 Jun 2024 03:28:38 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.174 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=1718249318; 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=1lhNM4y2L46tcjO0HaVOmUt/V/J9/oSem/zD16s3nQU=; b=tWaopnAvHrci93qGxppZNTSKPZvZ3jqK4QnavF+B3+jAyUIejBQhtQ56CM9GCo0HAP4Stj OljOjppp70JO0hVwSegfQmUcsd21FjBdASvIqCSyyTcp0VVsfxGpLYoyi/fgH/uNVphLQc /1e7cW8OUJgcTq0gSfmHgdK6yMxic20= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718249318; a=rsa-sha256; cv=none; b=vCW+exkUTvbpav5TF2oJLgAz/MXxzLmkplgLh0ZNPmbrkef27qlBzwqbtrGieoL4KnnBqh HV0dfS36ArJbsdLwSRDcyqMmc19d3MJByZKC3obWqSeOu88BFDwi2Fkcwzfgbxm3KV0yLw EGBqISt+g9Wfi5CG60p+YQ+BYAfgzv8= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-4e1c721c040so186206e0c.3 for ; Wed, 12 Jun 2024 20:28:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718249318; x=1718854118; 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=1lhNM4y2L46tcjO0HaVOmUt/V/J9/oSem/zD16s3nQU=; b=VbPGEnChZPZT/zGXPaIp+SJ58/JpFd8MukXoZAAzt77cMwTe72XOaKgMBgWnmATdZH vPvI7D4RhkUNOq5VubdXkySHwzXKfqzjtgwvsPa1NV4H6Xl3KNi7k7M7s37LSY3rEygE on7zFMovmfWlwIJyauRVpvPY3IkNpQ6f9vM2vARy7SUi8MyPXhCjnkJKggBeSGJAdkB8 C37IvZFfo577wKtmSUz/wxIbiOwv9p69mL+8iEG8BwTYeqzj7HV6M8hCmosT13JwUBl+ mQdFn5YQKdPe9/BZAsDB8YUJ6e3WCkEJdMjs03+8aTwDK2szM8uIFoCpCzRIV2URoWIY KIsg== X-Forwarded-Encrypted: i=1; AJvYcCViNGjh4A3kibRWPzfmXCIAccuNaXC/nq56g1wBPt3BAH9/44LWnsMllFPnD4+3v4XQ/JtsulheL/2XAhJqA71qjDw= X-Gm-Message-State: AOJu0YzTWMMUcdGfXZFfDxThIiYLut4ns2mmDfQAcc/OlPajJ+nLYfiC ZDGHSRQPGfHkGb7fnoA8VIINPgfQCZtQiO6e9xwhM0brBiG6FuJe39A2G2tYuqwfQvOuojT3+A5 hX0YXP0pSfnEguBxsLaqWrm57JLI= X-Google-Smtp-Source: AGHT+IER2m9h4J2ED0nainxeDLQuifIsGahGrZNtZTVvEFTbBmBIYVADnQWf3zikEVERXmvOfozYTe94r+45kRqOZQg= X-Received: by 2002:a05:6122:124e:b0:4da:ced8:b09a with SMTP id 71dfb90a1353d-4ed07720855mr3363389e0c.0.1718249318101; Wed, 12 Jun 2024 20:28:38 -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 15:28:26 +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-Queue-Id: 25CFA40004 X-Stat-Signature: id7cprti39bziu5nht7ibarax7ii9yrq X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1718249318-756145 X-HE-Meta: U2FsdGVkX1/SSpRIcP39V401TSUFxZ0xMWYSveuC6F4eKzFwuVJGtUbpcVksZFYkz3TTMmMbx3t1r8osRaYezZXxnJDCdqw1sBy+mUn2PSuAN9GtDZRi4eaJ7qaIJwKuVGFOWOxVO1I4XUvzloCMxLPF6lPjNVOqr9n4ZXJJ1Ytb1hYD9Y05elnEG0PQPxnE6Jb3U8Tzbf9vjalpeEJDKoR8uBMazJM9m5YfDgadbBV/HUC8a1OF6BVEAg7W1E6IHzleNi6ll5FDXFu097ip1qjMgy/46V31u0apRYGm8eWRKS1qGmcGx1BTKBLtkFrHtF6QwMHeyTQFHpSQIXuOLUh2z5I2InMQfesYLTPigPEeZw3KFc+ArVG0W0RIJTzqZoV66FlLKDgMD1hs8Cfx1buCE+9QCdhjGAoAjqP6z+lyx3hbiYE7uKEXHAQXY4eb36xB2SGyLDnyFzi+xlvwhyJIiVO5kYj1CIn+5Qaz9C4c1n7xRi5DTPjOjVieDI9Hs1xgQi90ZIVm72ITtoOwJu6nGzktqeM+xa/r0iji1LSKyhAQlTvwQPQAHVD5aZNrkLuvcx17gcQRIr32pVTYKT/7jE2vU0KhyYV1KNhyZOubRrhcUC7gyRR4GyWjk/CsmJXf/ge7rNyT76Wr9KePQKcvpL7dY9+112fFDo1cPae21UFMs6wWCf8o/EgPakaMu6bwwbjKmnyEnlfEocg0SsUjnPo6Dok63TKJlFAlc0FZV61HKVs1+Bi4s69SloRPE6z3E6EVwUj9s/hhKk6YMJM9BczHS7DYB9PE/YBggtk+LiJtmiJ/z/W/JmlnrhYqAYArwKys225qgqPdeYAVcNIZU2MfLiS/5VBw1aupdhI/qt68qWinx6HMIItoE3SRBuFt4pELkf/UwGTX0EaZs0YyKUlIoC0fyRYT8UGC2WzhsUkms+rN6ltLwCIznBWQF9leIcJW8/X2FsQi6y+ SId2lyCC huXDQI0cpQGsISqovWj4PVgoeirkBGKPSktxJAEQK/ZnHt99/jhJi/jk8YOsQ++RvZNsFgf8H405xhZmL8dP6COWGcX0Icd/Gfa4Z1F+HhnQO3jtp3DUN8Yf1Qje8OxjKAWcJfItunEQ81mLARU5QeJnlSnJhwxefmRQHREHAfui8Wmgt994digJwX6+fqodkHXgGZX/0FmZwYIRAX+L7but/54n5WBqWoqtD+CUGO9M+Me68mOukcdIauzgdxs78jhpYwLZm4yxURPTT3MGcFHSJ7lkHQkfSwSXdP4/Thnf4I+MjXP9fDmTnMs7OoKy2eZT8gAtN25ziyQ6Uhh5c794uGuQr5Jiab6h33R7afgxEJ3OsZH4LUjrWuhc2DBbua/YgZbm+zjbaPvagDAieeLsMUjOpYU+FN5jAuH7DLoXi8HyHr5m6PLOVTW7Z1ihMQ9DeIv2IIOq8lj0TqRq/sdj61yL6cL35y96bCjZKYeypSBMaHqvSPnD817svHFfbHwimFGviqRsMzcXCEHArEOR91sj7dygALIQLpiJOAYZM62M8ZXnDzbtOKVUyCCBrF/7riVyqwiSWkL4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 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 link= s or > > opening attachments. When in doubt, report the message using the 'Repor= t 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 debu= g. > > > > 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 develope= rs' > > > > judgment. > > > > I am not convinced that this patch is correct. If device-specific CMA i= s 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 flex= ible > > configuration options based on users=E2=80=99 needs. > > > > One significant benefit of device-specific CMA is that it helps decreas= e > > fragmentation in the common CMA pool. While many devices allocate memor= y > > 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 co= rrecting > > your device tree or cmdline configurations. > > > Because we enabled secure heap to support widevine DRM, and secure heap r= equires 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 not e= nough to support the VPU decoding high-resolution code streams, so this pat= ch 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? 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 be this big? So you have to "borr= ow" memory from the default CMA. but why not move that portion from the default CMA to your VPU=E2=80=99s CMA? Thanks Barry