Hello，Christian，T.J. 在 2026/11/7 01:25, T.J. Mercier 写道: > On Fri, Nov 6, 2026 at 5:23 AM Christian König <[email protected]> > wrote: >> >> On 11/6/26 14:18, Tao Cui wrote: >>> From: Tao Cui <[email protected]> >>> >>> udmabuf pins the pages of a memfd and hands them out as a dma-buf. The >>> data pages keep the accounting of the memfd they were instantiated in, >>> but the bookkeeping around them does not: the page pointer array and >>> the pinned_folios array, both sized by the buffer page count, plus the >>> transient folios array sized by the memfd folio count, are plain >>> GFP_KERNEL. A 1GB buffer costs about 4MB of uncharged SUnreclaim >>> memory, and size_limit_mb defaults to INT_MAX. >>> >>> Charge the three kvmalloc allocations so the creator pays for the >>> metadata it induces. The system heap in the same subsystem already >>> accounts its buffer allocation; > > Only if the mem_accounting param is set to true. We (Android) > currently depend on it being disabled because system heap buffers > don't have a single owner for their entire lifetime (ownership often > changes immediately after they are allocated), and the kernel doesn't > have the ability to switch who is charged for the buffer memory quite > yet. Albert is working hard on it at the moment. > > Could you update the message to note the mem_accounting param pls? > >>> the data pages here stay with the >>> memfd. > > memfd / udmabuf is a little special because it uses shmem for the > backing store, which is already tracked by memcg under all conditions > (except hugetlb). We don't currently use udmabuf, so the lack of memcg > charge transfer for udmabuf is not an issue. But once we get charge > transfer working for the system heap it'd be good to follow up with > udmabuf. > >> T.J. needs to take a look here, but I fear that this might break uAPI. > > Thanks for looping me in Christian. The buffer allocations cost > gigabytes, but these metadata arrays are only 4MB per 1GB of buffer, > so I don't expect charging them to break anyone. Leaving them > uncharged is an accounting gap though, since someone could spam many > udmabufs from the same memfd and only pay for the memfd pages once. So > this change is ok with me. > >> A lot of the DMA-buf resources are intentionally not charged against memcg. >> >> Regards, >> Christian. >> >>> >>> Signed-off-by: Tao Cui <[email protected]> > > With the commit message updated to mention the mem_accounting param: > Reviewed-by: T.J. Mercier <[email protected]> Thanks, Christian，T.J.
I'll update the commit message to clarify the mem_accounting parameter and pick up your Reviewed-by tag in v2. Tao
