From: Maxime Ripard <mripard@kernel.org>
To: "Andrew Morton" <akpm@linux-foundation.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"T.J. Mercier" <tjmercier@google.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Tomasz Figa" <tfiga@chromium.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
iommu@lists.linux.dev, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
Maxime Ripard <mripard@kernel.org>
Subject: [PATCH RFC 00/12] dma: Enable dmem cgroup tracking
Date: Mon, 10 Mar 2025 13:06:06 +0100 [thread overview]
Message-ID: <20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.org> (raw)
Hi,
Here's preliminary work to enable dmem tracking for heavy users of DMA
allocations on behalf of userspace: v4l2, DRM, and dma-buf heaps.
It's not really meant for inclusion at the moment, because I really
don't like it that much, and would like to discuss solutions on how to
make it nicer.
In particular, the dma dmem region accessors don't feel that great to
me. It duplicates the logic to select the proper accessor in
dma_alloc_attrs(), and it looks fragile and potentially buggy to me.
One solution I tried is to do the accounting in dma_alloc_attrs()
directly, depending on a flag being set, similar to what __GFP_ACCOUNT
is doing.
It didn't work because dmem initialises a state pointer when charging an
allocation to a region, and expects that state pointer to be passed back
when uncharging. Since dma_alloc_attrs() returns a void pointer to the
allocated buffer, we need to put that state into a higher-level
structure, such as drm_gem_object, or dma_buf.
Since we can't share the region selection logic, we need to get the
region through some other mean. Another thing I consider was to return
the region as part of the allocated buffer (through struct page or
folio), but those are lost across the calls and dma_alloc_attrs() will
only get a void pointer. So that's not doable without some heavy
rework, if it's a good idea at all.
So yeah, I went for the dumbest possible solution with the accessors,
hoping you could suggest a much smarter idea :)
Thanks,
Maxime
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
Maxime Ripard (12):
cma: Register dmem region for each cma region
cma: Provide accessor to cma dmem region
dma: coherent: Register dmem region for each coherent region
dma: coherent: Provide accessor to dmem region
dma: contiguous: Provide accessor to dmem region
dma: direct: Provide accessor to dmem region
dma: Create default dmem region for DMA allocations
dma: Provide accessor to dmem region
dma-buf: Clear cgroup accounting on release
dma-buf: cma: Account for allocations in dmem cgroup
drm/gem: Add cgroup memory accounting
media: videobuf2: Track buffer allocations through the dmem cgroup
drivers/dma-buf/dma-buf.c | 7 ++++
drivers/dma-buf/heaps/cma_heap.c | 18 ++++++++--
drivers/gpu/drm/drm_gem.c | 5 +++
drivers/gpu/drm/drm_gem_dma_helper.c | 6 ++++
.../media/common/videobuf2/videobuf2-dma-contig.c | 19 +++++++++++
include/drm/drm_device.h | 1 +
include/drm/drm_gem.h | 2 ++
include/linux/cma.h | 9 +++++
include/linux/dma-buf.h | 5 +++
include/linux/dma-direct.h | 2 ++
include/linux/dma-map-ops.h | 32 ++++++++++++++++++
include/linux/dma-mapping.h | 11 ++++++
kernel/dma/coherent.c | 26 +++++++++++++++
kernel/dma/direct.c | 8 +++++
kernel/dma/mapping.c | 39 ++++++++++++++++++++++
mm/cma.c | 21 +++++++++++-
mm/cma.h | 3 ++
17 files changed, 211 insertions(+), 3 deletions(-)
---
base-commit: 55a2aa61ba59c138bd956afe0376ec412a7004cf
change-id: 20250307-dmem-cgroups-73febced0989
Best regards,
--
Maxime Ripard <mripard@kernel.org>
next reply other threads:[~2025-03-10 12:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-10 12:06 Maxime Ripard [this message]
2025-03-10 12:06 ` [PATCH RFC 01/12] cma: Register dmem region for each cma region Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 02/12] cma: Provide accessor to cma dmem region Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 03/12] dma: coherent: Register dmem region for each coherent region Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 04/12] dma: coherent: Provide accessor to dmem region Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 05/12] dma: contiguous: " Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 06/12] dma: direct: " Maxime Ripard
2025-03-10 14:56 ` Robin Murphy
2025-03-10 16:28 ` Maxime Ripard
2025-03-10 18:44 ` Robin Murphy
2025-03-13 18:16 ` Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 07/12] dma: Create default dmem region for DMA allocations Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 08/12] dma: Provide accessor to dmem region Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 09/12] dma-buf: Clear cgroup accounting on release Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 10/12] dma-buf: cma: Account for allocations in dmem cgroup Maxime Ripard
2025-03-10 12:06 ` [PATCH RFC 11/12] drm/gem: Add cgroup memory accounting Maxime Ripard
2025-03-10 15:06 ` Robin Murphy
2025-03-10 12:06 ` [PATCH RFC 12/12] media: videobuf2: Track buffer allocations through the dmem cgroup Maxime Ripard
2025-03-10 12:15 ` [PATCH RFC 00/12] dma: Enable dmem cgroup tracking Maxime Ripard
2025-03-10 14:16 ` Christian König
2025-03-10 14:26 ` Maxime Ripard
2025-03-31 20:43 ` Dave Airlie
2025-04-01 11:03 ` Christian König
2025-04-03 6:07 ` Dave Airlie
2025-04-03 7:39 ` Christian König
2025-04-03 15:47 ` Maxime Ripard
2025-04-04 8:47 ` Christian König
2025-04-05 1:57 ` T.J. Mercier
2025-04-07 11:46 ` Christian König
2025-04-08 1:03 ` T.J. Mercier
2025-04-03 8:27 ` Simona Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.org \
--to=mripard@kernel.org \
--cc=Brian.Starkey@arm.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=benjamin.gaignard@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hverkuil@xs4all.nl \
--cc=iommu@lists.linux.dev \
--cc=jstultz@google.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mchehab@kernel.org \
--cc=robin.murphy@arm.com \
--cc=simona@ffwll.ch \
--cc=sumit.semwal@linaro.org \
--cc=tfiga@chromium.org \
--cc=tjmercier@google.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox