Re: [Linaro-mm-sig] [RFC 0/4] dma-buf Constraints-Enabled Allocation helpers

[Sumit Semwal]

Hi Laura,

On 13 October 2014 13:42, Laura Abbott <lauraa@xxxxxxxxxxxxxx> wrote:
> 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.
Apologies for the delay in response.
Since with cenalloc, the decision of 'which pool to allocate from' is
not with the userspace, but is calculated based on the devices that
attach, the userspace ABI should be just a simple xxx_create, which
returns an fd that'd be the dma-buf fd. That will allow easy sharing
with other dma-buf importers via standard dma-buf API.
>
> Thanks,
> Laura
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org â Open source software for ARM SoCs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/