Hi Tomasz,
On Friday 12 October 2012 10:24:34 Tomasz Stanislawski wrote:
On 10/11/2012 11:31 PM, Laurent Pinchart wrote:
On Wednesday 10 October 2012 16:46:42 Tomasz Stanislawski wrote:
Most operations on DMA and DMABUF framework need page aligned buffers.
The comment is a bit misleading, the buffer is already page-aligned (unless I'm mistaken dma_alloc_coherent() returns a page-aligned buffer) but its size isn't a multiple of the page size.
Ok. I will update the commit message that only buffer size is going to be page aligned.
Do we really need a page size multiple ? Isn't it enough to make the size a multiple of the cache line size ?
Frankly, I strongly oppose forcing a size of a DMA buffer to be rounded up.
However, I discovered a problem while testing mmap() interface in dma-buf. The test in dma_buf_mmap() will fail if the size is not a multiple of 4k.
Maybe the value from dma-buf.c:456 should be changed from:
dmabuf->size >> PAGE_SHIFT
to
PAGE_ALIGN(dmabuf->size) >> PAGE_SHIFT
However, I preferred to avoid any changes outside of the media tree hoping that the patchset gets merged. Rounding the buffer size to a page size was quick workaround for the issue with DMABUF mmap().
After some more thoughts I'm not sure whether this patch does the right thing. We have two sizes that we neeed to care about, the user usable buffer size and the allocated memory size.
When a user of a buffer requests buffer allocation with an explicit or implicit size we might need to allocate a larger buffer to fulfill usage requirements. We can thus end up with an allocated memory size larger than what the user requested. Such usage requirements include
- DMA and CPU access: when accessing the buffer both through DMA and directly by the CPU cache management comes into play, and the buffer address and size then need to be aligned to a cache line size boundary.
- Mapping to userspace: we can only map complete pages to userspace, the buffer address and size need to be aligned to a page size boundary to make sure that we won't leak unrelated data to userspace.
As the cache line size is smaller than a page fulfilling the second requirement always fulfills the first. There might be other requirements that escape my mind right now.
As we don't precisely know at allocation time how the buffer will be used (for instance whether it will eventually be mapped to userspace or not), we have two options:
- Align the buffer size to a page size boundary unconditionally.
- Let the user handle that requirement by specifying an allocation size aligned to a page size boundary.
Given the complexity associated with the second solution and the very small, if not inexistent, expected memory gain (when using the DMA allocation APIs we always get complete pages anyway, so there would be no gain in not aligning the allocation size to a page size boundary), I think the first solution should be preferred.
This leaves us with two questions related to buffer size: what size (between the requested size and the actually allocated size) do we report back to the user (in the v4l2_buffer length field for instance), and what size do we report to the dma-buf core (and thus to the other subsystems and other buffer users) ?