Received-SPF: pass (google.com: domain of linux-kernel+bounces-212521-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240612081216.1319089-1-zhai.he@nxp.com> <20240612114748.bf5983b50634f23d674bc749@linux-foundation.org>
 <CAGsJ_4wsAh8C08PXutYZx9xV3rLRwLG-E6Mq-JgoSO5LA1ns=A@mail.gmail.com> <AS1PR04MB9559D82F720BC9A64077186AEAC12@AS1PR04MB9559.eurprd04.prod.outlook.com>
In-Reply-To: <AS1PR04MB9559D82F720BC9A64077186AEAC12@AS1PR04MB9559.eurprd04.prod.outlook.com>
From: Barry Song <baohua@kernel.org>
Date: Thu, 13 Jun 2024 15:28:26 +1200
Message-ID: <CAGsJ_4zGRnGhn1zA1=H+TgqL8z59_Dy7x7YVKsKY0wRFt4tu9w@mail.gmail.com>
Subject: Re: [EXT] Re: [PATCH v2] Supports to use the default CMA when the
 device-specified CMA memory is not enough.
To: Zhai He <zhai.he@nxp.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, "sboyd@kernel.org" <sboyd@kernel.org>, 
	"linux-mm@kvack.org" <linux-mm@kvack.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Zhipeng Wang <zhipeng.wang_1@nxp.com>, 
	Jindong Yue <jindong.yue@nxp.com>, Christoph Hellwig <hch@lst.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 13, 2024 at 2:34=E2=80=AFPM Zhai He <zhai.he@nxp.com> wrote:
>
> > -----Original Message-----
> > From: Barry Song <baohua@kernel.org>
> > Sent: Thursday, June 13, 2024 5:37 AM
> > To: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Zhai He <zhai.he@nxp.com>; sboyd@kernel.org; linux-mm@kvack.org;
> > linux-kernel@vger.kernel.org; stable@vger.kernel.org; Zhipeng Wang
> > <zhipeng.wang_1@nxp.com>; Jindong Yue <jindong.yue@nxp.com>; Christoph
> > Hellwig <hch@lst.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 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 <akpm@linux-found=
ation.org>
> > wrote:
> > >
> > > On Wed, 12 Jun 2024 16:12:16 +0800 "zhai.he" <zhai.he@nxp.com> wrote:
> > >
> > > > From: He Zhai <zhai.he@nxp.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 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