From: subashrp@gmail.com (Subash Patel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RFC 0/2] ARM: DMA-mapping: new extensions for buffer sharing (part 2)
Date: Wed, 06 Jun 2012 19:15:40 +0530 [thread overview]
Message-ID: <4FCF5F04.7030207@gmail.com> (raw)
In-Reply-To: <1338988657-20770-1-git-send-email-m.szyprowski@samsung.com>
Hello Marek,
Thanks for the patch. We had found below two challenges when using UMM
related to the cache invalidate/flush after/before performing the DMA
operations:
a) when using HIGH_MEM pages, the page-table walk consumed lot of time
to get the KVA of each page. Moreover the overhead was from the spinlock
we acquire/release for each of the page.
b) One of my colleague tried to map/unmap the buffers only once instead
of every time(which results in this problem) and we didn't find
significant performance improvement. The reason is (as per my knowledge)
when we give address range to cache controller to invalidate/flush out,
the hardware operation is too fast(if there were any cache lines
associated with the pages at all) to add any overhead to the CPU operation.
But this patch makes logical flow for dma-mapping one step closer :) I
will adopt it as part of pulling all your new patches, and will keep you
updated of any new findings.
Regards,
Subash
On 06/06/2012 06:47 PM, Marek Szyprowski wrote:
> Hello,
>
> This is a continuation of the dma-mapping extensions posted in the
> following thread:
> http://thread.gmane.org/gmane.linux.kernel.mm/78644
>
> We noticed that some advanced buffer sharing use cases usually require
> creating a dma mapping for the same memory buffer for more than one
> device. Usually also such buffer is never touched with CPU, so the data
> are processed by the devices.
>
> From the DMA-mapping perspective this requires to call one of the
> dma_map_{page,single,sg} function for the given memory buffer a few
> times, for each of the devices. Each dma_map_* call performs CPU cache
> synchronization, what might be a time consuming operation, especially
> when the buffers are large. We would like to avoid any useless and time
> consuming operations, so that was the main reason for introducing
> another attribute for DMA-mapping subsystem: DMA_ATTR_SKIP_CPU_SYNC,
> which lets dma-mapping core to skip CPU cache synchronization in certain
> cases.
>
> The proposed patches have been generated on top of the ARM DMA-mapping
> redesign patch series on Linux v3.4-rc7. They are also available on the
> following GIT branch:
>
> git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git 3.4-rc7-arm-dma-v10-ext
>
> with all require patches on top of vanilla v3.4-rc7 kernel. I will
> resend them rebased onto v3.5-rc1 soon.
>
> Best regards
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
> Patch summary:
>
> Marek Szyprowski (2):
> common: DMA-mapping: add DMA_ATTR_SKIP_CPU_SYNC attribute
> ARM: dma-mapping: add support for DMA_ATTR_SKIP_CPU_SYNC attribute
>
> Documentation/DMA-attributes.txt | 24 ++++++++++++++++++++++++
> arch/arm/mm/dma-mapping.c | 20 +++++++++++---------
> include/linux/dma-attrs.h | 1 +
> 3 files changed, 36 insertions(+), 9 deletions(-)
>
next prev parent reply other threads:[~2012-06-06 13:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-06 13:17 [PATCH/RFC 0/2] ARM: DMA-mapping: new extensions for buffer sharing (part 2) Marek Szyprowski
2012-06-06 13:17 ` [PATCH 1/2] common: DMA-mapping: add DMA_ATTR_SKIP_CPU_SYNC attribute Marek Szyprowski
2012-06-06 13:17 ` [PATCH 2/2] ARM: dma-mapping: add support for " Marek Szyprowski
2012-06-06 13:45 ` Subash Patel [this message]
2012-06-18 7:50 ` [PATCH/RFC 0/2] ARM: DMA-mapping: new extensions for buffer sharing (part 2) Hiroshi Doyu
2012-06-18 9:03 ` Marek Szyprowski
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=4FCF5F04.7030207@gmail.com \
--to=subashrp@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).