From: "Christian König" <christian.koenig@amd.com>
To: Huan Yang <link@vivo.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 v2 0/5] Introduce DMA_HEAP_ALLOC_AND_READ_FILE heap flag
Date: Tue, 30 Jul 2024 12:42:30 +0200 [thread overview]
Message-ID: <fe460c96-fb5f-41e7-8312-a2aa30140042@amd.com> (raw)
In-Reply-To: <25cf34bd-b11f-4097-87b5-39e6b4a27d85@vivo.com>
Am 30.07.24 um 11:05 schrieb Huan Yang:
>
> 在 2024/7/30 16:56, Daniel Vetter 写道:
>> [????????? daniel.vetter@ffwll.ch ?????????
>> https://aka.ms/LearnAboutSenderIdentification?????????????]
>>
>> On Tue, Jul 30, 2024 at 03:57:44PM +0800, Huan Yang wrote:
>>> UDMA-BUF step:
>>> 1. memfd_create
>>> 2. open file(buffer/direct)
>>> 3. udmabuf create
>>> 4. mmap memfd
>>> 5. read file into memfd vaddr
>> Yeah this is really slow and the worst way to do it. You absolutely want
>> to start _all_ the io before you start creating the dma-buf, ideally
>> with
>> everything running in parallel. But just starting the direct I/O with
>> async and then creating the umdabuf should be a lot faster and avoid
> That's greate, Let me rephrase that, and please correct me if I'm wrong.
>
> UDMA-BUF step:
> 1. memfd_create
> 2. mmap memfd
> 3. open file(buffer/direct)
> 4. start thread to async read
> 3. udmabuf create
>
> With this, can improve
>
>> needlessly serialization operations.
>>
>> The other issue is that the mmap has some overhead, but might not be too
>> bad.
> Yes, the time spent on page fault in mmap should be negligible
> compared to the time spent on file read.
You should try to avoid mmap as much as possible. Especially the TLB
invalidation overhead is really huge on platforms with a large number of
CPUs.
Regards,
Christian.
>> -Sima
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
next prev parent reply other threads:[~2024-07-30 10:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-30 7:57 [PATCH v2 0/5] Introduce DMA_HEAP_ALLOC_AND_READ_FILE heap flag Huan Yang
2024-07-30 7:57 ` [PATCH v2 1/5] dma-buf: heaps: " Huan Yang
2024-07-31 11:08 ` kernel test robot
2024-07-30 7:57 ` [PATCH v2 2/5] dma-buf: heaps: Introduce async alloc read ops Huan Yang
2024-07-30 7:57 ` [PATCH v2 3/5] dma-buf: heaps: support alloc async read file Huan Yang
2024-07-31 14:44 ` kernel test robot
2024-07-30 7:57 ` [PATCH v2 4/5] dma-buf: heaps: system_heap alloc support async read Huan Yang
2024-07-30 7:57 ` [PATCH v2 5/5] dma-buf: heaps: configurable async read gather limit Huan Yang
2024-07-30 8:03 ` [PATCH v2 0/5] Introduce DMA_HEAP_ALLOC_AND_READ_FILE heap flag Christian König
2024-07-30 8:14 ` Huan Yang
2024-07-30 8:37 ` Christian König
2024-07-30 8:46 ` Huan Yang
2024-07-30 10:43 ` Christian König
2024-07-30 11:36 ` Huan Yang
2024-07-30 13:11 ` Christian König
2024-07-31 1:48 ` Huan Yang
2024-07-30 17:19 ` T.J. Mercier
2024-07-31 1:47 ` Huan Yang
2024-07-30 8:56 ` Daniel Vetter
2024-07-30 9:05 ` Huan Yang
2024-07-30 10:42 ` Christian König [this message]
2024-07-30 11:33 ` Huan Yang
2024-07-30 12:04 ` Huan Yang
2024-07-31 20:46 ` Daniel Vetter
2024-08-01 2:53 ` Huan Yang
2024-08-05 17:53 ` Daniel 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=fe460c96-fb5f-41e7-8312-a2aa30140042@amd.com \
--to=christian.koenig@amd.com \
--cc=Brian.Starkey@arm.com \
--cc=benjamin.gaignard@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jstultz@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=link@vivo.com \
--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