All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.