Hi Frank,
On Fri, 28 Feb 2025 at 19:30, Frank van der Linden <fvdl@xxxxxxxxxx> wrote:
> Currently, CMA manages one range of physically contiguous memory.
> Creation of larger CMA areas with hugetlb_cma may run in to gaps
> in physical memory, so that they are not able to allocate that
> contiguous physical range from memblock when creating the CMA
> area.
>
> This can happen, for example, on an AMD system with > 1TB of memory,
> where there will be a gap just below the 1TB (40bit DMA) line. If
> you have set aside most of memory for potential hugetlb CMA allocation,
> cma_declare_contiguous_nid will fail.
>
> hugetlb_cma doesn't need the entire area to be one physically
> contiguous range. It just cares about being able to get physically
> contiguous chunks of a certain size (e.g. 1G), and it is fine
> to have the CMA area backed by multiple physical ranges, as
> long as it gets 1G contiguous allocations.
>
> Multi-range support is implemented by introducing an array of
> ranges, instead of just one big one. Each range has its own bitmap.
> Effectively, the allocate and release operations work as before,
> just per-range. So, instead of going through one large bitmap, they
> now go through a number of smaller ones.
>
> The maximum number of supported ranges is 8, as defined in
> CMA_MAX_RANGES.
>
> Since some current users of CMA expect a CMA area to just use one
> physically contiguous range, only allow for multiple ranges if a
> new interface, cma_declare_contiguous_nid_multi, is used. The other
> interfaces will work like before, creating only CMA areas with
> 1 range.
>
> cma_declare_contiguous_nid_multi works as follows, mimicking the
> default "bottom-up, above 4G" reservation approach:
>
> 0) Try cma_declare_contiguous_nid, which will use only one
> region. If this succeeds, return. This makes sure that for
> all the cases that currently work, the behavior remains
> unchanged even if the caller switches from
> cma_declare_contiguous_nid to cma_declare_contiguous_nid_multi.
> 1) Select the largest free memblock ranges above 4G, with
> a maximum number of CMA_MAX_RANGES.
> 2) If we did not find at most CMA_MAX_RANGES that add
> up to the total size requested, return -ENOMEM.
> 3) Sort the selected ranges by base address.
> 4) Reserve them bottom-up until we get what we wanted.
>
> Cc: Arnd Bergmann <arnd@xxxxxxxx>
> Signed-off-by: Frank van der Linden <fvdl@xxxxxxxxxx>
Thanks for your patch, which is now commit c009da4258f9885c
("mm, cma: support multiple contiguous ranges, if requested")
in v6.15-rc1.
After this patch, the printed base address becomes zero on several
Renesas arm32/arm64 platforms:
- Koelsch (R-Car M2-W):
-cma: Reserved 64 MiB at 0x7c000000 on node -1
+cma: Reserved 64 MiB at 0x00000000
- Salvator-XS (R-Car H3 ES2.0):
-cma: Reserved 128 MiB at 0x0000000078000000 on node -1
+cma: Reserved 128 MiB at 0x0000000000000000
- Gray Hawk Single (R-Car V4H):
-cma: Reserved 128 MiB at 0x00000000b8000000 on node -1
+cma: Reserved 128 MiB at 0x0000000000000000
None of these have actual RAM at address zero. As I haven't noticed
any other impact on system operation, I do not know if this is purely
a cosmetic issue, or if it can cause real problems.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
