On 10/10/2014 1:07 PM, Sumit Semwal wrote:
Hi,
Why:
====
While sharing buffers using dma-buf, currently there's no mechanism to let
devices share their memory access constraints with each other to allow for
delayed allocation of backing storage.
This RFC attempts to introduce the idea of memory constraints of a device,
and how these constraints can be shared and used to help allocate buffers that
can satisfy requirements of all devices attached to a particular dma-buf.
How:
====
A constraints_mask is added to dma_parms of the device, and at the time of
each device attachment to a dma-buf, the dma-buf uses this constraints_mask
to calculate the access_mask for the dma-buf.
Allocators can be defined for each of these constraints_masks, and then helper
functions can be used to allocate the backing storage from the matching
allocator satisfying the constraints of all devices interested.
A new miscdevice, /dev/cenalloc [1] is created, which acts as the dma-buf
exporter to make this transparent to the devices.
More details in the patch description of "cenalloc: Constraint-Enabled
Allocation helpers for dma-buf".
At present, the constraint_mask is only a bitmask, but it should be possible to
change it to a struct and adapt the constraint_mask calculation accordingly,
based on discussion.
Important requirement:
======================
Of course, delayed allocation can only work if all participating devices
will wait for other devices to have 'attached' before mapping the buffer
for the first time.
As of now, users of dma-buf(drm prime, v4l2 etc) call the attach() and then
map_attachment() almost immediately after it. This would need to be changed if
they were to benefit from constraints.
What 'cenalloc' is not:
=======================
- not 'general' allocator helpers - useful only for constraints-enabled
devices that share buffers with others using dma-buf.
- not a replacement for existing allocation mechanisms inside various
subsystems; merely a possible alternative.
- no page-migration - it would be very complementary to the delayed allocation
suggested here.
TODOs:
======
- demonstration test cases
- vma helpers for allocators
- more sample allocators
- userspace ioctl (It should be a simple one, and we have one ready, but wanted
to agree on the kernel side of things first)
I'm interested to see the userspace ioctl. The mask based approach of
Ion does not scale well to a userspace ABI so I'm curious if cenalloc
does better.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
