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? > > 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
