[RFC PATCH v1] dma-buf: heaps: move the verification of heap_flags to the corresponding heap

[Hailong Liu]

On 6/4/2024 11:33 PM, John Stultz wrote:
> On Mon, Jun 3, 2024 at 11:30 PM Hailong Liu <hailong.liu at oppo.com> wrote:
>> On 6/4/2024 2:06 AM, John Stultz wrote:
>>> On Mon, Jun 3, 2024 at 10:21 AM Hailong Liu <hailong.liu at oppo.com> wrote:
>>>> We now aim to improve priority dma-buf allocation. Consider android
>>>> animations scene:
>>>>
>>>> when device is in low memory, Allocating dma-buf as animation
>>>> buffers enter direct_reclaimation, longer allocation time result in a
>>>> laggy UI. But if we know the usage of the dma-buf, we can use some
>>>> mechanisms to boost, e.g. animation-memory-pool.
>>>
>>> Can you generalize this a bit further? When would userland know to use
>>> this new flag?
>>> If it is aware, would it make sense to just use a separate heap name instead?
>>>
>>> (Also: These other mechanisms you mention should probably also be
>>> submitted upstream, however for upstream there's also the requirement
>>> that we have open users and are not just enabling proprietary blob
>>> userspace, which makes any changes to dma-buf heaps for out of tree
>>> code quite difficult)
>>>
>>>> However, dma-buf usage identification becomes a challenge. A potential
>>>> solution could be heap_flags. the use of heap_flags seems ugly and
>>>> contrary to the intended design as you said, How aboult extending
>>>> dma_heap_allocation_data as follows?
>>>>
>>>> struct dma_heap_allocation_data {
>>>>         __u64 len;
>>>>         __u32 fd;
>>>>         __u32 fd_flags;
>>>>         __u64 heap_flags;
>>>>         __u64 buf_flags: // buf usage
>>>> };
>>>
>>> This would affect the ABI (forcing a new ioctl number).  And it's
>>> unclear what flags you envision as buffer specific (rather than heap
>>> specific as this patch suggested).
>>>
>>> I think we need more details about the specific problem you're seeing
>>> and trying to resolve.
>> This patch mainly focuses on optimization for Android scenarios. Let’s
>> discuss it on the issue website.
>> Bug: 344501512
> 
> Ok, we can do that if you need.
> 
> But if this is ever going to go upstream (and it's more and more
> important that we minimize out of tree technical debt), conversations
> about how to generalize this will need to happen on the list.
> We need a more complete design and test results to convince upstream to accept. 
Thank you again for your suggestion.

Brs, 
Hailong.
> thanks
> -john