From: Huan Yang <link@vivo.com>
To: "Christoph Hellwig" <hch@infradead.org>,
"Christian König" <christian.koenig@amd.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"T.J. Mercier" <tjmercier@google.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
opensource.kernel@vivo.com
Subject: Re: [PATCH 1/2] dma-buf: heaps: DMA_HEAP_IOCTL_ALLOC_READ_FILE framework
Date: Wed, 24 Jul 2024 15:12:55 +0800 [thread overview]
Message-ID: <276e29fa-1252-4c91-a5e4-eaf367b4fbb0@vivo.com> (raw)
In-Reply-To: <Zpf5R7fRZZmEwVuR@infradead.org>
在 2024/7/18 1:03, Christoph Hellwig 写道:
> copy_file_range only work inside the same file system anyway, so
> it is completely irrelevant here.
>
> What should work just fine is using sendfile (or splice if you like it
> complicated) to write TO the dma buf. That just iterates over the page
> cache on the source file and calls ->write_iter from the page cache
> pages. Of course that requires that you actually implement
> ->write_iter, but given that dmabufs support mmaping there I can't
> see why you should not be able to write to it.
This day, I test dma-buf read large file with sendfile. Here are two
problem I find when read O_DIRECT open file.
1. sendfile/splice transfer data between read and write through a pipe.
Even if the read process does not generate page cache, an
equivalent amount of CPU copy is still required.
This is particularly noticeable in the performance degradation when
reading large files.
2. Each pipe max_bytes is 64K(in my phone and arch test), This means
that for each IO, only 64K is read and then copied, resulting in poor IO
performance.
Based on observations from testing, it takes an average of 7s to perform
O_DIRECT read of a 3GB file. Trace show much runable and running and
some I/O between this.
For buffer read large file into dma-buf by sendfile, cost 2.3s, is normal.
Maybe this is not a good way to let dma-buf support direct IO?
>
> Reading FROM the dma buf in that fashion should also work if you provide
> a ->read_iter wire up ->splice_read to copy_splice_read so that it
We current more care abount read file into dma-buf, not write. :)
> doesn't require any page cache.
next prev parent reply other threads:[~2024-07-24 7:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-11 7:42 [PATCH 0/2] Introduce DMA_HEAP_IOCTL_ALLOC_AND_READ Huan Yang
2024-07-11 7:42 ` [PATCH 1/2] dma-buf: heaps: DMA_HEAP_IOCTL_ALLOC_READ_FILE framework Huan Yang
2024-07-11 9:00 ` Christian König
2024-07-11 9:18 ` Huan Yang
2024-07-11 11:39 ` Christian König
2024-07-12 1:59 ` Huan Yang
2024-07-12 2:14 ` Huan Yang
2024-07-12 7:10 ` Christian König
2024-07-12 7:29 ` Huan Yang
2024-07-12 7:41 ` Christian König
2024-07-12 7:52 ` Huan Yang
2024-07-12 10:59 ` Christian König
2024-07-12 11:12 ` Huan Yang
2024-07-15 9:11 ` Daniel Vetter
2024-07-15 12:32 ` Christian König
2024-07-16 2:48 ` Huan Yang
2024-07-16 9:31 ` Daniel Vetter
2024-07-16 10:14 ` Huan Yang
2024-07-17 15:15 ` Daniel Vetter
2024-07-17 17:03 ` Christoph Hellwig
2024-07-18 1:51 ` Huan Yang
2024-07-18 3:08 ` Christoph Hellwig
2024-07-18 3:12 ` Huan Yang
2024-07-24 7:12 ` Huan Yang [this message]
[not found] ` <d3ad46ea-df7f-4402-b48a-349e957f198b@amd.com>
2024-07-17 7:33 ` Huan Yang
2024-07-17 15:23 ` Daniel Vetter
2024-07-13 10:33 ` kernel test robot
2024-07-11 7:42 ` [PATCH 2/2] dma-buf: heaps: system_heap support DMA_HEAP_IOCTL_ALLOC_AND_READ Huan Yang
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=276e29fa-1252-4c91-a5e4-eaf367b4fbb0@vivo.com \
--to=link@vivo.com \
--cc=Brian.Starkey@arm.com \
--cc=benjamin.gaignard@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@infradead.org \
--cc=jstultz@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=opensource.kernel@vivo.com \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
/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