lkml.org 
[lkml]   [2024]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] dma-buf: add DMA_BUF_IOCTL_SYNC_PARTIAL support
    On Tue, Apr 9, 2024 at 12:34 AM Rong Qianfeng <11065417@vivo.com> wrote:
    >
    >
    > 在 2024/4/8 15:58, Christian König 写道:
    > > Am 07.04.24 um 09:50 schrieb Rong Qianfeng:
    > >> [SNIP]
    > >>> Am 13.11.21 um 07:22 schrieb Jianqun Xu:
    > >>>> Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf with
    > >>>> offset and len.
    > >>>
    > >>> You have not given an use case for this so it is a bit hard to
    > >>> review. And from the existing use cases I don't see why this should
    > >>> be necessary.
    > >>>
    > >>> Even worse from the existing backend implementation I don't even see
    > >>> how drivers should be able to fulfill this semantics.
    > >>>
    > >>> Please explain further,
    > >>> Christian.
    > >> Here is a practical case:
    > >> The user space can allocate a large chunk of dma-buf for
    > >> self-management, used as a shared memory pool.
    > >> Small dma-buf can be allocated from this shared memory pool and
    > >> released back to it after use, thus improving the speed of dma-buf
    > >> allocation and release.
    > >> Additionally, custom functionalities such as memory statistics and
    > >> boundary checking can be implemented in the user space.
    > >> Of course, the above-mentioned functionalities require the
    > >> implementation of a partial cache sync interface.
    > >
    > > Well that is obvious, but where is the code doing that?
    > >
    > > You can't send out code without an actual user of it. That will
    > > obviously be rejected.
    > >
    > > Regards,
    > > Christian.
    >
    > In fact, we have already used the user-level dma-buf memory pool in the
    > camera shooting scenario on the phone.
    >
    > From the test results, The execution time of the photo shooting
    > algorithm has been reduced from 3.8s to 3s.
    >
    For phones, the (out of tree) Android version of the system heap has a
    page pool connected to a shrinker. That allows you to skip page
    allocation without fully pinning the memory like you get when
    allocating a dma-buf that's way larger than necessary. If it's for a
    camera maybe you need physically contiguous memory, but it's also
    possible to set that up.

    https://android.googlesource.com/kernel/common/+/refs/heads/android14-6.1/drivers/dma-buf/heaps/system_heap.c#377


    > To be honest, I didn't understand your concern "...how drivers should be
    > able to fulfill this semantics." Can you please help explain it in more
    > detail?
    >
    > Thanks,
    >
    > Rong Qianfeng.
    >
    > >
    > >>
    > >> Thanks
    > >> Rong Qianfeng.
    > >
    >

    \
     
     \ /
      Last update: 2024-04-09 18:37    [W:3.223 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site