On 5/19/26 01:00, Barry Song wrote: > 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?
Yes, exactly that. > 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. Well that's the current proposal, but I think we need to come up with something more general. > 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. Yeah but that's not only for DMA-buf, we need that for file descriptors returned by memfd_create() as well. Regards, Christian. > Best Regards > Barry
