Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas

--rscp6jw7dv2pn33g
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas
MIME-Version: 1.0

On Wed, Jul 08, 2026 at 10:59:46AM +0200, David Hildenbrand (Arm) wrote:
> On 7/1/26 18:08, Thierry Reding wrote:
> > From: Thierry Reding <[email protected]>
> >=20
> > There is no technical reason why there should be a limited number of CMA
> > regions, so extract some code into helpers and use them to create extra
> > functions (cma_create() and cma_free()) that allow creating and freeing,
> > respectively, CMA regions dynamically at runtime.
>=20
> I'm confused. We still allow cma_create() only during __init, right?
>=20
> Would we expect callers of cma_free() after __init? Or at which point?

The idea is to allow cma_create() at any point. I forgot to properly
remove the various __init annotations to make that clear. I've done that
for the next revision.

Technically cma_free() could happen any time a user no longer needs it.
While we currently only do this on error-unwind, the Tegra VPR driver
could technically be turned into a module and the entire region be torn
down at that point, including calling cma_free() on all the chunks. I
don't think we ever want to do that and it'd require a bit of tweaking
to the OF reserved-memory code, but generally speaking I don't see why
we wouldn't want to allow cma_create() and cma_free() at any time after
__init.

> > The static array of CMA areas cannot be replaced by dynamically created
> > areas because for many of them, allocation must not fail and some cases
> > may need to initialize them before the slab allocator is even available.
>=20
> We can start with a memblock array of an initial size (like we do today).
>=20
> Then, when you need more space, we can double the size (copying content a=
nd
> exchanging the pointer). Either allocate from memblock or from slab, if
> available (slab_is_available).
>=20
> memblock does something similar, see memblock_double_array().

After replying to T.J. I think this static array is actually a nice
feature in a way. It allows us to more easily make a distinction between
the regular CMA regions created from reserved-memory regions that
represent classic carveouts, and the more versatile CMA areas that could
be used for any purpose.

Telling the two types apart could obviously also be solved using some
kind of flag stored with the CMA area, but at this point I don't really
see a reason why the two lists would need to be unified.

Thierry

--rscp6jw7dv2pn33g
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmp0tsYACgkQ3SOs138+
s6EDqQ//VPlX14ZCCWQFTzMM+CH1U7z90n2OI2r6sVAf3mIXAqF56hCOe1TSTHch
SLJpzBAU/F15bA6jirr2jOS8SHr7N0C+ox5M2yoEGywgGsbTEOjWSvejWrHWkJ9m
7fdcdEl/hB7yzbpBvDMxGiATg+0SwQrhy4Sp7105QzaPpE3/9dS5UXbQuhsbCcAy
4fU7Xd3wOOLcxg5u7Fl0ggfWHiAX68o32alTzPijPaVubxFJ1RnLQLeNhTdwJv03
nvh3RVR8dpDTY7hZbsTr/4r5+4L3ktGvufT5m3K0lImfKVb5hklsKVbNTnQMtJ+i
nAC+BTofn33vMautsZwPhhAQeesfMSJkuNASPD9kqZ0U+b+W7XtmmkmwbigS2r9u
1lajCmiV77/KeZazBydPFJzqt+0lEkLAwWtBAk+M/Fw0Lsx3/ycfApXqEtCv/Jfw
G1oTIraXEv0tXgSbl0Q0zAY/TKTgTmtNqVNbLJh2VxhQiicJGiEYZ9w7i971TlUs
obsrwFtpOrWdkBI8VFGUm59sNK7yjrl2XWpejZ+xmhY4GanpuNYf/Ki6nBhTn39r
qUNyB63c492tlL7PYUHVx1tMFCMwDBPw9wg5Dn57++j5s3gmoAmgqaAykpl/tuhB
lRoRWYWo4mgQ/C62svXRtyqVx5TMhQpRLrpQOAGdx4y6SF4GmGk=
=TjKb
-----END PGP SIGNATURE-----

--rscp6jw7dv2pn33g--