Re: [PATCH 0/3] dma-mapping: Improve atomic pool behaviour

[Vladimir Kondratiev <Vladimir.Kondratiev@mobileye.com>]

> 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] Suspicious Link - Removed
> [2] Suspicious Link - Removed
> 
> 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

Tested-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

Tested on platform: upcoming Mobileye eyeq7h - risc-v platform with memory
mapped to 32Gbytes so DMA32 zone is empty