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

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

On 4/28/26 10:37, Feng Tang wrote:
> Hi David,

Hi!

[...]

>>
>> Okay, so on x86 it is not silent, because they don't even have a default CMA area?
> 
> 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
> 
>>>
>>> One thought is to follow the current cma reserving policy for platform
>>> with 'CONFIG_DMA_NUMA_CMA=y', that if the numa cma (either the 'numa cma'
>>> or 'cma pernuma' method) is not explicitly configured, set it up
>>> according to size of default 'dma_contiguous_default_area', while
>>> skipping the numa node where the 'dma_contiguous_default_area' lies
>>> in, this way the default behavior of platform with one NUMA node is
>>> kept unchanged.
>>
>> So, the kernel is configured to have a certain CONFIG_CMA_SIZE_MBYTES size, but
>> you go ahead and multiply that by the number of nodes? Sounds wrong.
> 
> 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.

> 
> Robin did concern about the memory usage for embedded/small devices in
> v2 review, and we change to v3 to not affect them.
> 
>>
>> The whole proposal here looks rather hacky.
> 
> I agree :)
> 
>> Wouldn't a default for e.g., pernuma_size_bytes make more sense, that users can
>> then overwrite on the cmdline?
>  
> 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.

[...]

>>> +extern int cma_get_nid(const struct cma *cma)
>>> +{
>>> +	return cma->nid;
>>> +}
>>
>> Why do you have to store the nid instead of just looking it up from the base_pfn
>> in here?
> 
> 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 :)

> 
>>
>> Also, what is the expectation when the ranges would span different NIDs? (is
>> that possible?)
> 
> 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.

-- 
Cheers,

David