Effects of adjusting coherent_pool kernel parameter value

[moonwalkers]

The CMA is for drivers that want to allocate large chunks of contiguous memory.  Usually this is because the driver needs to DMA a lot of data and doesn't support scatter-gather.  You can see how much CMA is free by looking at CmaFree in /proc/meminfo.

coherent_pool just sets the initial size of the coherent DMA pools.  They will expand if needed if the kernel is new enough to have that feature, which I think is less than a year old. But this happens in the background, so there is some early value needed before the kernel is running processes to do the expanding, which is what this controls.  So as long as the device drivers needed for booting have enough it shouldn't need to be increased.

The current size of the coherent pools can been seen in /sys/kernel/debug/dma_pools/pool_size_*.  Mine PBP has them only at 512kB, which was the initial value.

The coherent pools are allocated from the CMA area, so if there is no CMA, then they can't be allocated.

It seems a bit surprising that setting both CMA and coherent to zero works.  I'd guess that many something ignores the value of zero and treats that as a request to allocate the default.  Or that nothing needs coherent on boot and it can be expanded if/when necessary, so there are no errors.  Traditionally, ARM systems did not have coherent DMA prior to ARMv8, so there are probably not a lot of users in the code that runs on a PBP.

Thank you for the explanation!

From the linked LWN article my understanding is CMA is not strictly necessary for DMA buffer allocation, but rather is intended to help with it - to keep a contiguous memory area where those buffers can be easily allocated even when they need to be quite big. At the moment in /proc/meminfo CmaTotal is listed as 0kB, while the pools are at 128KiB, 256KiB, and 128KiB for dma, dma32, and kernel respectively, despite coherent_pool=0 in command line.

I've seen some posts out there talking about some drivers having issue when coherent_pool is too low, though in at least one case the issue was solved not by increasing coherent_pool value, but by increasing CMA, which I suppose makes sense if the pools prefer to use CMA when present and fail to expand if CMA is not large enough...

I guess my takeaway is that so long as I can boot fine and I don't see any drivers complaining in the kernel log - I can just remove those parameters from the command line and leave the kernel defaults be. Though I still wonder why coherent_pool is explicitly configured in Pinebook Pro... Could it be that without that setting NVMe SSD initialization may fail? I don't have NVMe adapter/drive to verify myself.