Posted Oct 18, 2011 2:32 UTC (Tue) by bgat (guest, #20709)
Parent article: CMA and ARM
I don't think the performance degradation due to memory splits will be significant, because CMA will not be used as a general allocator: it will be used for very large allocations, of which there will be few. Thus we are talking about a small number of splits in a typical system.
But Russell's objection is a significant one. If we go with CMA as-is, we risk an API whose behavior changes across platforms. We can't have that, or the whole point of CMA (in my view) is lost. We may as well stick with the magic numbers in our code that we have now.
Unfortunately, CMA is at least two tangentially-related things at once: a command-line syntax for expressing large memory regions that the kernel shall avoid, and an implementation for allocations from those regions. Embedded developers are in critical need of both, but I for one would be pretty happy if we could just get the API in for now so that we could standardize what the solution would look like.
At least in the near term, I wouldn't care if the mainlined "CMA" API was just dma_alloc_coherent() under the hood. I am willing to accept severe caveats in its use so long as my drivers I am writing now stay reasonably source-compatible with the implementation of CMA as it improves over time.