On Tue, May 12, 2026 at 5:18 PM Albert Esteve <[email protected]> wrote: > > On embedded platforms a central process often allocates dma-buf > memory on behalf of client applications. Without a way to > attribute the charge to the requesting client's cgroup, the > cost lands on the allocator, making per-cgroup memory limits > ineffective for the actual consumers. > > Add charge_pid_fd to struct dma_heap_allocation_data. When set to > a valid pidfd, DMA_HEAP_IOCTL_ALLOC resolves the target task's > memcg and charges the buffer there via mem_cgroup_charge_dmabuf() > inside dma_heap_buffer_alloc(). Without charge_pid_fd, and with > the mem_accounting module parameter enabled, the buffer is charged > to the allocator's own cgroup. > > Additionally, commit 3c227be90659 ("dma-buf: system_heap: account for > system heap allocation in memcg") adds __GFP_ACCOUNT to system-heap > page allocations. Keeping __GFP_ACCOUNT would charge the same pages > twice (once to kmem, once to MEMCG_DMABUF), thus remove it and route > all accounting through a single MEMCG_DMABUF path. > [...]
> - if (mem_accounting) > - flags |= __GFP_ACCOUNT; Hi Albert, would it be better to move this and its description to patch 1? It looks like patch 1 already introduces the double accounting changes, and patch 2 is mainly just supporting remote charging. Also, mem_accounting is only used by system_heap.c; has this patchset also eliminated its need? Thanks Barry
