linux-kernel - Re: [EXT] Re: [PATCH v2] Supports to use the default CMA when the device-specified CMA memory is not enough.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGsJ_4zGRnGhn1zA1=H+TgqL8z59_Dy7x7YVKsKY0wRFt4tu9w@mail.gmail.com>
Date: Thu, 13 Jun 2024 15:28:26 +1200
From: Barry Song <baohua@...nel.org>
To: Zhai He <zhai.he@....com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, "sboyd@...nel.org" <sboyd@...nel.org>, 
	"linux-mm@...ck.org" <linux-mm@...ck.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Zhipeng Wang <zhipeng.wang_1@....com>, 
	Jindong Yue <jindong.yue@....com>, Christoph Hellwig <hch@....de>
Subject: Re: [EXT] Re: [PATCH v2] Supports to use the default CMA when the
 device-specified CMA memory is not enough.

On Thu, Jun 13, 2024 at 2:34 PM Zhai He <zhai.he@....com> wrote:
>
> > -----Original Message-----
> > From: Barry Song <baohua@...nel.org>
> > Sent: Thursday, June 13, 2024 5:37 AM
> > To: Andrew Morton <akpm@...ux-foundation.org>
> > Cc: Zhai He <zhai.he@....com>; sboyd@...nel.org; linux-mm@...ck.org;
> > linux-kernel@...r.kernel.org; stable@...r.kernel.org; Zhipeng Wang
> > <zhipeng.wang_1@....com>; Jindong Yue <jindong.yue@....com>; Christoph
> > Hellwig <hch@....de>
> > 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 AM Andrew Morton <akpm@...ux-foundation.org>
> > wrote:
> > >
> > > On Wed, 12 Jun 2024 16:12:16 +0800 "zhai.he" <zhai.he@....com> wrote:
> > >
> > > > From: He Zhai <zhai.he@....com>
> > >
> > > (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 mislead 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 options based on users’ 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 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 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’t quite understand what you are saying. Why can’t you increase
VPU’s 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’t 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’s CMA?

Thanks
Barry