From: Milan Zamazal <mzamazal@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: iommu@lists.linux.dev, Will Deacon <will@kernel.org>,
catalin.marinas@arm.com,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Andrey Konovalov <andrey.konovalov.ynk@gmail.com>,
Pavel Machek <pavel@ucw.cz>, Maxime Ripard <mripard@redhat.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
kieran.bingham@ideasonboard.com,
Hans de Goede <hdegoede@redhat.com>
Subject: Uncached buffers from CMA DMA heap on some Arm devices?
Date: Wed, 24 Jan 2024 19:27:31 +0100 [thread overview]
Message-ID: <87bk9ahex7.fsf@redhat.com> (raw)
Hello,
in the libcamera project, we experience a major performance problem related to
DMA buffers while working on camera image processing using CPU. This happens
only with some Arm boards, we have observed it on Debix Model A (NXP i.MX 8M
Plus) and PinePhone. We use /dev/dma_heap/linux,cma (or reserved) DMA buffer
heap on Arm.
Reading V4L2 camera data from buffers is very slow. When we memcpy the data
from the buffer to a malloc'ed memory before working with it (reading each byte
multiple times, without any big non-sequential jumps across the data), we get
more than 10 times speed up. It looks like the input buffer is uncached.
We experience slow down also when writing to output buffers. It doesn't seem to
matter whether we write to the output byte-by-byte or memcpy larger chunks.
We are having trouble to understand what's the problem with the buffers on some
hardware and what we can realistically do about it. Could you please help us
clarify this? Is it possible to force the DMA buffer CMA heap to be cached?
Or is there anything else we can do or try?
Thank you,
Milan
next reply other threads:[~2024-01-24 18:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 18:27 Milan Zamazal [this message]
2024-01-25 11:41 ` Uncached buffers from CMA DMA heap on some Arm devices? Lucas Stach
2024-01-26 11:22 ` Milan Zamazal
2024-01-26 12:19 ` Maxime Ripard
2024-01-26 12:17 ` Maxime Ripard
2024-01-29 12:05 ` Laurent Pinchart
2024-01-29 10:23 ` Pavel Machek
2024-01-29 10:32 ` Maxime Ripard
2024-01-29 12:07 ` Laurent Pinchart
2024-01-29 13:12 ` Lucas Stach
2024-01-29 18:30 ` Pavel Machek
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=87bk9ahex7.fsf@redhat.com \
--to=mzamazal@redhat.com \
--cc=andrey.konovalov.ynk@gmail.com \
--cc=bryan.odonoghue@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=hch@lst.de \
--cc=hdegoede@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=mripard@redhat.com \
--cc=pavel@ucw.cz \
--cc=will@kernel.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.