Re: [PATCH v3] dma-contiguous: setup default numa cma area if not configured explicitly

["David Hildenbrand (Arm)" <david@kernel.org>]

On 5/6/26 17:46, Feng Tang wrote:
> On Fri, May 01, 2026 at 08:51:39PM +0200, David Hildenbrand (Arm) wrote:
>> On 4/28/26 10:37, Feng Tang wrote:
>>> Hi David,
>>
>> Hi!
>>
>> [...]
>>
>>>
>>> Right for default kernel configs.
>>>
>>> In kernel/dma/Kconfig:
>>>
>>> config CMA_SIZE_MBYTES
>>> 	int "Size in Mega Bytes"
>>> 	depends on !CMA_SIZE_SEL_PERCENTAGE
>>> 	default 0 if X86
>>> 	default 16
>>>
>>> config CMA_SIZE_PERCENTAGE
>>> 	int "Percentage of total memory"
>>> 	depends on !CMA_SIZE_SEL_MBYTES
>>> 	default 0 if X86
>>> 	default 10
>>>
>>>
>>> Yes. I thought about that, and didn't have good solution, and used this
>>> given it's on a multi-numa-node machine, which may not be too bad
>>> regarding memory usage.
>>
>> It sounds wrong given the existing config options.
> 
> Yes, it is confusing. 
> 
>>>
>>> Robin did concern about the memory usage for embedded/small devices in
>>> v2 review, and we change to v3 to not affect them.
>>>
>>>
>>> I agree :)
>>>
>>>  
>>> This sounds good to me, if no objection from others. Maybe default 64MB
>>> or more. One good part is, all these setup is under protection of
>>> CONFIG_DMA_NUMA_CMA. 
>>
>> I cannot do the heavy thinking here because -EBUSY, but maybe you want a config
>> option similar to CMA_SIZE_MBYTES/CMA_SIZE_PERCENTAGE that either controls that
>> these sizes will be split over NUMA nodes, or another one, that sets the default
>> for pernuma.
> 
> Maybe a CMA_NUMA_SIZE_MBYTES?

Maybe, I'm hoping some CMA DMA people have the capacity to provide input.

>  
>> [...]
>>
>>>
>>> My thought was 'struct cma' already have 'nid' member, and when CONFIG_NUMA=y,
>>> it may be useful to save the 'nid' info instead of NUMA_NO_NODE for the default
>>> cma area (cmdline like cma=XXG@YYG could make it on different node)
>>
>> Ah, yeah. It's a bit nasty that we have to handle the default area like that.
>>
>> Another sign that we probably shouldn't deal with the default area :)
> 
> Yep, in v2 I didn't touch the default area, while Robin had a concern
> that the v2 approach will bindly add an extra per-numa cma area for
> the node which already has the default area, which will hurt those
> small/embedded devices which has limited number of memory. Adding
> the nid check is trying to keep the behavior of one node device
> unchanged.
> 
>>>
>>>
>>> Per my understanding, it won't. There is a cma_validate_zones() to prevent it
>>> from crossing zones.
>>
>> It's a bit confusing, because it ignores other nids.
> 
> I might have missed your point. Do you mean one cma are could have
> multiple ranges?

I don't know, it's confusing :)

-- 
Cheers,

David