From: Karl Mehltretter <kmehltretter@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: "Christian König" <christian.koenig@amd.com>,
linux-media@vger.kernel.org, "Tomasz Figa" <tfiga@chromium.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Hans de Goede" <hansg@kernel.org>,
"Hans Verkuil" <hverkuil@kernel.org>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Tomasz Stanislawski" <t.stanislaws@samsung.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] media: synchronize CPU access to imported DMA-BUFs
Date: Tue, 20 Oct 2026 05:24:54 +0200 [thread overview]
Message-ID: <atbbdKshkbmbMZMk@gmail.com> (raw)
In-Reply-To: <20261019150116.GA3705@killaraus.ideasonboard.com>
Hi Laurent,
On Mon, Oct 19, 2026 at 06:01:16PM +0100, Laurent Pinchart wrote:
>
> This patch series introduces a big penalty in the common case where a
> userspace application consumes the frame with the CPU. There should be
> no cache invalidation in that case.
>
I measured this on my Pi 500+. The cost appears when the DMA-BUF has a
V3D attachment that stays mapped but idle. I compared patch 1 alone with
patches 1-4 on the same v7.3-rc4 base at 640x480 YUYV. For the DMA-BUF
runs, userspace read every frame between DMA_BUF_IOCTL_SYNC READ calls.
Median process CPU time (us/frame), five 1800-frame runs:
patch 1 patches 1-4
DMA-BUF, no DRM import 129.2 130.6
DMA-BUF, idle V3D map 130.0 153.1
MMAP 126.5 125.4
The no-import and MMAP ranges overlapped. The V3D-mapped ranges did not.
Pi 400 reproduced the mapped cost with vivid (+8.7%) and UVC (+7.5%).
The task-clock profile covered only the patched mapped path:
Operation Sample share
DQBUF producer END|WRITE clean 26%
userspace START|READ invalidation 13%
userspace END|READ clean 8%
I tried a CMA experiment that kept the DMA-BUF callbacks but skipped the
read-only END|READ attachment sync. The skip variant saved a median 12.3
us/frame (8.0%) across three alternating same-boot pairs. With private
DMA-BUFs, the full-sync and skip variants both passed 64 byte-checked
V3D read and overwrite cycles after END|READ.
That experiment still performs END|WRITE and START|READ. In a negative
control without END|WRITE, all eight V3D reads returned stale data.
Patch 1 is independent, so I can send it separately.
For patches 2-4: How should vb2 avoid the END|WRITE/START|READ
round trip when userspace consumes the frame with the CPU, while still
publishing the frame if the next consumer is a device?
Thanks,
Karl
next prev parent reply other threads:[~2026-10-20 3:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 7:14 [PATCH 0/4] media: synchronize CPU access to imported DMA-BUFs Karl Mehltretter
2026-10-19 7:14 ` [PATCH 1/4] media: videobuf2: finish prepared buffers in VIDIOC_REMOVE_BUFS Karl Mehltretter
2026-10-19 7:14 ` [PATCH 2/4] media: videobuf2: add opt-in DMA-BUF CPU access Karl Mehltretter
2026-10-19 7:14 ` [PATCH 3/4] media: uvcvideo: synchronize imported DMA-BUFs for " Karl Mehltretter
2026-10-19 7:14 ` [PATCH 4/4] media: vivid: " Karl Mehltretter
2026-10-19 12:44 ` [PATCH 0/4] media: synchronize CPU access to imported DMA-BUFs Laurent Pinchart
2026-10-19 14:48 ` Christian König
2026-10-19 15:01 ` Laurent Pinchart
2026-10-20 3:24 ` Karl Mehltretter [this message]
2026-10-20 3:09 ` Karl Mehltretter
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=atbbdKshkbmbMZMk@gmail.com \
--to=kmehltretter@gmail.com \
--cc=benjamin.gaignard@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hansg@kernel.org \
--cc=hverkuil@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=t.stanislaws@samsung.com \
--cc=tfiga@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.