From: Marek Szyprowski <m.szyprowski@samsung.com>
To: "'Daniel Vetter'" <daniel@ffwll.ch>,
"'Konrad Rzeszutek Wilk'" <konrad.wilk@oracle.com>
Cc: linux-arch@vger.kernel.org,
"'Abhinav Kochhar'" <abhinav.k@samsung.com>,
"'Russell King - ARM Linux'" <linux@arm.linux.org.uk>,
"'Arnd Bergmann'" <arnd@arndb.de>,
"'Benjamin Herrenschmidt'" <benh@kernel.crashing.org>,
linux-kernel@vger.kernel.org,
"'Subash Patel'" <subash.ramaswamy@linaro.org>,
linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org,
"'Kyungmin Park'" <kyungmin.park@samsung.com>,
linux-arm-kernel@lists.infradead.org
Subject: RE: [Linaro-mm-sig] [PATCHv2 0/6] ARM: DMA-mapping: new extensions for buffer sharing
Date: Thu, 14 Jun 2012 10:47:48 +0200 [thread overview]
Message-ID: <002901cd4a0a$667e1600$337a4200$%szyprowski@samsung.com> (raw)
In-Reply-To: <20120613190131.GO4829@phenom.ffwll.local>
Hello,
On Wednesday, June 13, 2012 9:02 PM Daniel Vetter wrote:
> On Wed, Jun 13, 2012 at 10:12:12AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jun 13, 2012 at 01:50:12PM +0200, Marek Szyprowski wrote:
> (snipped)
> > > The third extension solves the performance issues which we observed with
> > > some advanced buffer sharing use cases, which require creating a dma
> > > mapping for the same memory buffer for more than one device. 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.
>
> Ah, here's the use-case I've missed ;-) I'm a bit vary of totally insane
> platforms that have additional caches only on the device side, and only
> for some devices. Well, tlbs belong to that, but the iommu needs to handle
> that anyway.
>
> I think it would be good to add a blurb to the documentation that any
> device-side flushing (of tlbs or special caches or whatever) still needs
> to happen and that this is only a performance optimization to avoid the
> costly cpu cache flushing. This way the dma-buf exporter could keep track
> of whether it's 'device-coherent' and set that flag if the cpu caches don't
> need to be flushed.
>
> Maybe also make it clear that implementing this bit is optional (like your
> doc already mentions for NO_KERNEL_MAPPING).
Ok, I can add additional comment, but support for all dma attributes is optional
(attributes are considered only as hints that might improve performance for some
use cases on some hw platforms).
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
next prev parent reply other threads:[~2012-06-14 8:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 11:50 Marek Szyprowski
2012-06-13 11:50 ` [PATCHv2 1/6] common: DMA-mapping: add DMA_ATTR_NO_KERNEL_MAPPING attribute Marek Szyprowski
2012-06-13 18:52 ` [Linaro-mm-sig] " Daniel Vetter
2012-06-14 9:01 ` Marek Szyprowski
2012-06-13 11:50 ` [PATCHv2 2/6] ARM: dma-mapping: add support for " Marek Szyprowski
2012-06-13 11:50 ` [PATCHv2 3/6] common: dma-mapping: introduce dma_get_sgtable() function Marek Szyprowski
2012-06-13 18:52 ` [Linaro-mm-sig] " Daniel Vetter
2012-06-13 11:50 ` [PATCHv2 4/6] ARM: dma-mapping: add support for dma_get_sgtable() Marek Szyprowski
2012-06-13 11:50 ` [PATCHv2 5/6] common: DMA-mapping: add DMA_ATTR_SKIP_CPU_SYNC attribute Marek Szyprowski
2012-06-13 18:45 ` [Linaro-mm-sig] " Daniel Vetter
2012-06-13 11:50 ` [PATCHv2 6/6] ARM: dma-mapping: add support for " Marek Szyprowski
2012-06-13 14:12 ` [PATCHv2 0/6] ARM: DMA-mapping: new extensions for buffer sharing Konrad Rzeszutek Wilk
2012-06-13 19:01 ` [Linaro-mm-sig] " Daniel Vetter
2012-06-14 8:47 ` Marek Szyprowski [this message]
2012-06-14 8:39 ` 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='002901cd4a0a$667e1600$337a4200$%szyprowski@samsung.com' \
--to=m.szyprowski@samsung.com \
--cc=abhinav.k@samsung.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=daniel@ffwll.ch \
--cc=konrad.wilk@oracle.com \
--cc=kyungmin.park@samsung.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=subash.ramaswamy@linaro.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
all inboxes | Powered by JetHome®