On Mon, May 18, 2026 at 9:34 AM 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. > > >>> 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? > > Well apart from DMA-buf memfd_create() is one of the things which as broken > our neck in the past a couple of times. > > But thinking more about it what if instead of making this DMA-buf heaps > specific what if we have a general cgroups function which allows to change > accounting of a buffer referenced by a file descriptor to a different process? > > That would cover not only the DMA-buf heaps use case, but also all other > DMA-buf with dmem and whatever we come up in the future as well.
I removed a draft adding an ioctl for charge transfer from the series before sending because I wanted to focus on the charge_pid_fd approach and keep things simple, deferring the recharge path to a follow-up depending on feedback. The main difference between my removed draft and what you're describing, iiuc, is scope and layer: my draft was an explicit ioctl on the dma-buf fd that the consumer calls to claim the charge (see below), while you seem to be suggesting a more general kernel-internal function that could work across buffer types and cgroup controllers, so not necessarily userspace-initiated? A kernel-internal function will need a way to identify the target process, which sounds similar to the binder-backed approach from TJ [1]. For everything else, the receiver still needs to declare itself, which the ioctl accomplishes. ``` # When an app imports a daemon-allocated buffer, it can transfer the charge to itself: int buf_fd = receive_dmabuf_from_daemon(); ioctl(buf_fd, DMA_BUF_IOCTL_XFER_CHARGE); /* charge now attributed to apps's cgroup */ ``` [1] https://lore.kernel.org/cgroups/[email protected]/ > > The only drawback I can see is that DMA-buf heap allocations would be > temporarily accounted to the memory allocation daemon, but I don't think that > this would be a problem. The main reasons we moved away from TJ's transfer-based approach toward `charge_pid_fd` are: avoid the transient charge window on the daemon's cgroup; and to decouple from Binder, allowing any allocator to use it. Technically, both approaches could coexist, though. Of the three scenarios TJ described: - Scenario 2 is directly addressed by charge_pid_fd approach without any transient charge on the daemon at the cost of one extra field in the heap ioctl uAPI struct. - Scenario 3 can be handled by the charge transfer function without changes to SurfaceFlinger. The app or dequeueBuffer claims the charge for itself or the app, respectively (depending on whether we include a pid_fd field in the transfer ioctl). It also covers non-heap exporters. The con in both variants is the transient charge window on the daemon. Both approaches shift the responsibility for correct charging attribution to userspace: first, 'charge_pid_fd` on the allocator's side, and the transfer charge on the consumer's side. Deciding on one, the other or both depends on how much we value avoiding transient attribution, and how much we need a non-heap generic solution. With the XFER_CHARGE we can cover both. Thus, the `charge_pid_fd` approach in this RFC can be seen as a performance/strictness optimisation, eliminating transient charges to the daemon at the cost of a permanent uAPI addition to the heap ioctl struct, but not strictly required for correctness. On the other hand, if we agree on the end goal of migrating other exporters to use dma-buf heaps, and scenario 3 is addressed by adding the app's pid_fd to SurfaceFlinger, then `charge_pid_fd` alone is a coherent/sufficient approach despite the uAPI change. > > Regards, > Christian. > > > > > Thanks > > Barry >
