Hi all,

These days we have somewhat of a matrix of mm zones that may or may not
exist and may or may not be empty, which the per-zone atomic pool logic
doesn't actually handle all that well. It's not all that difficult to
improve robustness and reduce redundancy, so that's what this series
aims for.

I initially wrote this just because I happened to be looking through the
boot log of one of my boards and had one of those out-of-the-blue
realisations of "hang on, why *is* it allocating pools for zones it
doesn't even have memory in?", but coincidentally, it seems that others
happened to notice related aspects around the same time[1][2]. This is
my attempt to sort it all out properly.

I guess this could go via either the dma-mapping or mm tree, whichever
maintainers prefer.

Thanks,
Robin.


[1] https://lore.kernel.org/linux-iommu/20260112065857.3137331-1-vladimir.kondratiev@mobileye.com/
[2] https://lore.kernel.org/linux-iommu/20260112104749.4132641-1-s-adivi@ti.com/

Robin Murphy (3):
  dma/pool: Improve pool lookup
  mm_zone: Generalise has_managed_dma()
  dma/pool: Avoid allocating redundant pools

 include/linux/mmzone.h |  9 +++++----
 kernel/dma/pool.c      | 27 ++++++++++++++++++---------
 mm/page_alloc.c        |  8 ++------
 3 files changed, 25 insertions(+), 19 deletions(-)

-- 
2.34.1

On 01/12/26 at 03:46pm, Robin Murphy wrote:
> Hi all,
> 
> These days we have somewhat of a matrix of mm zones that may or may not
> exist and may or may not be empty, which the per-zone atomic pool logic
> doesn't actually handle all that well. It's not all that difficult to
> improve robustness and reduce redundancy, so that's what this series
> aims for.
> 
> I initially wrote this just because I happened to be looking through the
> boot log of one of my boards and had one of those out-of-the-blue
> realisations of "hang on, why *is* it allocating pools for zones it
> doesn't even have memory in?", but coincidentally, it seems that others
> happened to notice related aspects around the same time[1][2]. This is
> my attempt to sort it all out properly.

Reviewed-by: Baoquan He <bhe@redhat.com>

On 12.01.2026 16:46, Robin Murphy wrote:
> These days we have somewhat of a matrix of mm zones that may or may not
> exist and may or may not be empty, which the per-zone atomic pool logic
> doesn't actually handle all that well. It's not all that difficult to
> improve robustness and reduce redundancy, so that's what this series
> aims for.
>
> I initially wrote this just because I happened to be looking through the
> boot log of one of my boards and had one of those out-of-the-blue
> realisations of "hang on, why *is* it allocating pools for zones it
> doesn't even have memory in?", but coincidentally, it seems that others
> happened to notice related aspects around the same time[1][2]. This is
> my attempt to sort it all out properly.
>
> I guess this could go via either the dma-mapping or mm tree, whichever
> maintainers prefer.

I will take this patchset to dma-mapping-fixes branch, thanks!

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland