On Thu, May 14, 2026 at 12:35 AM T.J. Mercier tjmercier@google.com 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?
udmabufs are already memcg-charged, so adding a separate MEMCG_DMABUF would double count. Are there any other exporters you had in mind that would benefit from this approach?
Thanks Barry