On Mon, May 18, 2026 at 3:34 PM Christian König <[email protected]> wrote: > > On 5/16/26 11:19, Barry Song wrote: > > On Thu, May 14, 2026 at 12:35 AM T.J. Mercier <[email protected]> wrote: > > [...] > >>>> I have a question about this part. Albert I guess you are interested > >>>> only in accounting dmabuf-heap allocations, or do you expect to add > >>>> __GFP_ACCOUNT or mem_cgroup_charge_dmabuf calls to other > >>>> non-dmabuf-heap exporters? > >>> > >>> We're scoping this to dma-buf heaps for now. CMA heaps and the dmem > >>> controller are on the radar for follow-up/parallel work (there will be > >>> dragons and will surely need discussion). For DRM and V4L2 the > >>> long-term intent is migration to heaps, which would make direct > >>> accounting on those paths unnecessary. > >> > >> Ah I see. GEM buffers exported to dmabufs are what I had in mind. I > >> guess this would only leave the odd non-DRM driver with the need to > >> add their own accounting calls, which I don't expect would be a big > >> problem. > >> > > > > sounds like we still have a long way to go to correctly account for > > various v4l2, drm, GEM, CMA, etc. In patch 1, the charging is done in > > dma_buf_export(), so I guess it covers all dma-buf types except > > dma_heap, but the problem is that it has no remote charging support at > > all? > > No, just the other way around > > DMA-buf heaps can be handled here because we know that it is pure system > memory and nothing special so memcg always applies. > > dma_buf_export() on the other hand handles tons of different use cases, > ranging from buffer accounted to dmem, over special resources which aren't > even memory all the way to buffers which can migrate from dmem to memcg and > back during their lifetime. >
Hi Christian, Thanks very much for your explanation. So basically it seems that dma_buf_export() is not the proper place to charge, since it may end up mixing in non-system-memory accounting? My question is also about the global view for both heap and non-heap cases. After reading the discussion, I’ve tried to summarize it—please let me know if my understanding is correct. for dma_heap, we have the ioctl DMA_HEAP_IOCTL_ALLOC, where users can pass a remote pidfd or similar information to indicate where the dma-buf should be charged, as in Albert's patchset. For non-dma_heap dma-bufs, we don’t have an obvious userspace entry point that triggers the allocation. So we likely need other approaches. We could either move more drivers over to dma-heap, or introduce something like DMA_BUF_IOCTL_XFER_CHARGE, as you are discussing, to let userspace explicitly declare a charge. Best Regards Barry
