Re: [PATCH 04/11] dma-contiguous: pass the NUMA node to dma_alloc_contiguous()

[Robin Murphy <robin.murphy@arm.com>]

On 2026-11-12 3:43 pm, Paolo Abeni wrote:
> On 11/12/26 14:28, Robin Murphy wrote:
>> On 2026-11-12 9:53 am, Paolo Abeni wrote:
>>> On 11/6/26 19:44, Jakub Kicinski wrote:
>>>> --- a/kernel/dma/mapping.c
>>>> +++ b/kernel/dma/mapping.c
>>>> @@ -642,6 +642,13 @@ EXPORT_SYMBOL_GPL(dma_get_required_mask);
>>>>    * Same as dma_alloc_attrs() but places the memory on @node rather 
>>>> than on the
>>>>    * node of @dev. Like with kmalloc_node() the node is only a 
>>>> preference,
>>>>    * the page allocator may fall back to other nodes if @node is out 
>>>> of memory.
>>>> + * The contiguous memory allocator (CMA) does not: only the CMA 
>>>> area of @node
>>>> + * and the global CMA area are tried. The allocation may fail even 
>>>> though the
>>>> + * CMA area of another node, e.g. that of @dev, still has free space.
>>>> + *
>>>> + * Allocations served from per-device or global coherent pools, 
>>>> per- device CMA
>>>> + * areas, restricted or atomic pools, arch_dma_alloc() or dma_map_ops
>>>> + * implementations do not take @node into account.
>>> I'm possibly over-thinking here, but AFAICS there are a bunch of 
>>> dma_map_ops that
>>> are using dev_to_node():
>>>
>>> dma_iommu_alloc_coherent() in arch/powerpc/kernel/dma-iommu.c
>>> vio_dma_iommu_alloc_coherent() in arch/powerpc/platforms/pseries/vio.c
>>> gart_alloc_coherent() in arch/x86/kernel/amd_gart_64.c
>>>
>>> With this series they will stop using the driver provided numa node.
>>> Probably not a blocker but possibly worth to call out?
>>
>> Nothing "stops" - this series adds a *new* interface by which drivers 
>> can now indicate a specific preferred node, but DMA API backends are 
>> still free to ignore the caller-provided hint and continue doing 
>> whatever they want. This is already called out all over the series in 
>> commit messages, documentation and comments including the one above.
> I mean: the series also replaces the old hacks with the new APIs usage
> in a few drivers, and in the above cases there could be actual regressions.
> 
> But I guess we could handle them if and when they will surface.

Ah, sorry, I was confused by the comment being made in the context of 
this patch - what you mean is that in patches 6-11, the new API isn't 
guaranteed to give the same result as the set_dev_node() hacks being 
removed? To be fair, the new API itself still does not change any 
behaviour, removing the hacks changes the behaviour ;)

I guess it could be worth a note in those commit messages if we think 
there's a chance that anyone is using these NICs on POWER systems that 
might conceivably observe a performance blip.

Cheers,
Robin.