On 11/6/26 14:18, Tao Cui wrote:
From: Tao Cui cuitao@kylinos.cn
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; the data pages here stay with the memfd.
T.J. needs to take a look here, but I fear that this might break uAPI.
A lot of the DMA-buf resources are intentionally not charged against memcg.
Regards, Christian.
Signed-off-by: Tao Cui cuitao@kylinos.cn
drivers/dma-buf/udmabuf.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index df6dd0046242..40182c82df6b 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -190,11 +190,12 @@ static void unpin_all_folios(struct udmabuf *ubuf)
static __always_inline int init_udmabuf(struct udmabuf *ubuf, pgoff_t pgcnt) {
ubuf->pages = kvmalloc_objs(*ubuf->pages, pgcnt);
ubuf->pages = kvmalloc_objs(*ubuf->pages, pgcnt, GFP_KERNEL_ACCOUNT); if (!ubuf->pages) return -ENOMEM;
ubuf->pinned_folios = kvmalloc_objs(*ubuf->pinned_folios, pgcnt);
ubuf->pinned_folios = kvmalloc_objs(*ubuf->pinned_folios, pgcnt,GFP_KERNEL_ACCOUNT); if (!ubuf->pinned_folios) return -ENOMEM;@@ -387,7 +388,7 @@ static long udmabuf_create(struct miscdevice *device, if (ret) goto err;
folios = kvmalloc_objs(*folios, max_nr_folios);
folios = kvmalloc_objs(*folios, max_nr_folios, GFP_KERNEL_ACCOUNT); if (!folios) { ret = -ENOMEM; goto err;-- 2.43.0
On Fri, Nov 6, 2026 at 5:23 AM Christian König christian.koenig@amd.com wrote:
On 11/6/26 14:18, Tao Cui wrote:
From: Tao Cui cuitao@kylinos.cn
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 cuitao@kylinos.cn
With the commit message updated to mention the mem_accounting param: Reviewed-by: T.J. Mercier tjmercier@google.com
On 11/6/26 18:25, T.J. Mercier wrote:
On Fri, Nov 6, 2026 at 5:23 AM Christian König christian.koenig@amd.com wrote:
On 11/6/26 14:18, Tao Cui wrote:
From: Tao Cui cuitao@kylinos.cn
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.
Good point, making sure that Albert is on CC as well.
So basically we not only need to charge the backing store of a DMA-buf to somebody else, but also the housekeeping overhead.
Mhm, this here also complicates the charge transfer Albert is working on.
@Albert not something we need to take care about now, but please keep that in mind while working on that stuff.
Regards, Christian.
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 cuitao@kylinos.cn
With the commit message updated to mention the mem_accounting param: Reviewed-by: T.J. Mercier tjmercier@google.com
On Mon, Nov 9, 2026 at 11:56 AM Christian König christian.koenig@amd.com wrote:
On 11/6/26 18:25, T.J. Mercier wrote:
On Fri, Nov 6, 2026 at 5:23 AM Christian König christian.koenig@amd.com wrote:
On 11/6/26 14:18, Tao Cui wrote:
From: Tao Cui cuitao@kylinos.cn
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.
Good point, making sure that Albert is on CC as well.
So basically we not only need to charge the backing store of a DMA-buf to somebody else, but also the housekeeping overhead.
For system heaps the housekeeping size is fixed at creation so it kindof fits the reservation model nicely. We'd only need it to account for the overhead (as part of the MEMCG_DMABUF stat probably).
Mhm, this here also complicates the charge transfer Albert is working on.
The transfer would just move the charge as a single unit. But yeah, the complexity will come from lazy exporters or any other exporter where the bookkeeping grows or changes.
@Albert not something we need to take care about now, but please keep that in mind while working on that stuff.
Noted. The issue already exists so my series does not make it worse. I will note this for a follow up series.
Thanks for tagging me!
BR, Albert
Regards, Christian.
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 cuitao@kylinos.cn
With the commit message updated to mention the mem_accounting param: Reviewed-by: T.J. Mercier tjmercier@google.com
linaro-mm-sig@lists.linaro.org
-
Albert Esteve -
Christian König -
T.J. Mercier