From: "Andrew F. Davis" <afd@ti.com> To: Liam Mark <lmark@codeaurora.org>, Christoph Hellwig <hch@infradead.org> Cc: Laura Abbott <labbott@redhat.com>, <sumit.semwal@linaro.org>, <arve@android.com>, <tkjos@android.com>, <maco@android.com>, <joel@joelfernandes.org>, <christian@brauner.io>, <devel@driverdev.osuosl.org>, <dri-devel@lists.freedesktop.org>, <linaro-mm-sig@lists.linaro.org>, <linux-kernel@vger.kernel.org>, <john.stultz@linaro.org> Subject: Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes Date: Tue, 22 Jan 2019 10:06:07 -0600 [thread overview] Message-ID: <8d87ffa0-0710-fc82-ef87-50843fe3a4ee@ti.com> (raw) In-Reply-To: <alpine.DEB.2.10.1901211357140.11004@lmark-linux.qualcomm.com> On 1/21/19 4:12 PM, Liam Mark wrote: > On Mon, 21 Jan 2019, Christoph Hellwig wrote: > >> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote: >>> The main use case is for allowing clients to pass in >>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance >>> which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In >>> ION the buffers aren't usually accessed from the CPU so this allows >>> clients to often avoid doing unnecessary cache maintenance. >> >> This can't work. The cpu can still easily speculate into this area. > > Can you provide more detail on your concern here. > The use case I am thinking about here is a cached buffer which is accessed > by a non IO-coherent device (quite a common use case for ION). > > Guessing on your concern: > The speculative access can be an issue if you are going to access the > buffer from the CPU after the device has written to it, however if you > know you aren't going to do any CPU access before the buffer is again > returned to the device then I don't think the speculative access is a > concern. > >> Moreover in general these operations should be cheap if the addresses >> aren't cached. >> > > I am thinking of use cases with cached buffers here, so CMO isn't cheap. > These buffers are cacheable, not cached, if you haven't written anything the data wont actually be in cache. And in the case of speculative cache filling the lines are marked clean. In either case the only cost is the little 7 instruction loop calling the clean/invalidate instruction (dc civac for ARMv8) for the cache-lines. Unless that is the cost you are trying to avoid? In that case if you are mapping and unmapping so much that the little CMO here is hurting performance then I would argue your usage is broken and needs to be re-worked a bit. Andrew > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project >
WARNING: multiple messages have this Message-ID (diff)
From: "Andrew F. Davis" <afd@ti.com> To: Liam Mark <lmark@codeaurora.org>, Christoph Hellwig <hch@infradead.org> Cc: devel@driverdev.osuosl.org, tkjos@android.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, arve@android.com, joel@joelfernandes.org, maco@android.com, christian@brauner.io Subject: Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes Date: Tue, 22 Jan 2019 10:06:07 -0600 [thread overview] Message-ID: <8d87ffa0-0710-fc82-ef87-50843fe3a4ee@ti.com> (raw) In-Reply-To: <alpine.DEB.2.10.1901211357140.11004@lmark-linux.qualcomm.com> On 1/21/19 4:12 PM, Liam Mark wrote: > On Mon, 21 Jan 2019, Christoph Hellwig wrote: > >> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote: >>> The main use case is for allowing clients to pass in >>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance >>> which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In >>> ION the buffers aren't usually accessed from the CPU so this allows >>> clients to often avoid doing unnecessary cache maintenance. >> >> This can't work. The cpu can still easily speculate into this area. > > Can you provide more detail on your concern here. > The use case I am thinking about here is a cached buffer which is accessed > by a non IO-coherent device (quite a common use case for ION). > > Guessing on your concern: > The speculative access can be an issue if you are going to access the > buffer from the CPU after the device has written to it, however if you > know you aren't going to do any CPU access before the buffer is again > returned to the device then I don't think the speculative access is a > concern. > >> Moreover in general these operations should be cheap if the addresses >> aren't cached. >> > > I am thinking of use cases with cached buffers here, so CMO isn't cheap. > These buffers are cacheable, not cached, if you haven't written anything the data wont actually be in cache. And in the case of speculative cache filling the lines are marked clean. In either case the only cost is the little 7 instruction loop calling the clean/invalidate instruction (dc civac for ARMv8) for the cache-lines. Unless that is the cost you are trying to avoid? In that case if you are mapping and unmapping so much that the little CMO here is hurting performance then I would argue your usage is broken and needs to be re-worked a bit. Andrew > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-01-22 16:06 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-18 18:37 [PATCH 0/4] ION stability and perf changes Liam Mark 2019-01-18 18:37 ` [PATCH 1/4] staging: android: ion: Support cpu access during dma_buf_detach Liam Mark 2019-01-18 18:37 ` Liam Mark 2019-01-18 19:34 ` Andrew F. Davis 2019-01-18 19:34 ` Andrew F. Davis 2019-01-18 20:40 ` Laura Abbott 2019-01-18 18:37 ` [PATCH 2/4] staging: android: ion: Restrict cache maintenance to dma mapped memory Liam Mark 2019-01-18 18:37 ` Liam Mark 2019-01-18 20:20 ` Andrew F. Davis 2019-01-18 20:20 ` Andrew F. Davis 2019-01-18 21:18 ` Liam Mark 2019-01-18 21:18 ` Liam Mark 2019-01-29 23:44 ` Liam Mark 2019-01-29 23:44 ` Liam Mark 2019-01-30 11:31 ` Brian Starkey 2019-01-30 11:31 ` Brian Starkey 2019-02-06 15:40 ` [Linaro-mm-sig] " Ørjan Eide 2019-02-07 7:31 ` Christoph Hellwig 2019-02-07 7:31 ` Christoph Hellwig 2019-02-07 15:45 ` Ørjan Eide 2019-02-28 23:49 ` Liam Mark 2019-01-30 14:31 ` Andrew F. Davis 2019-01-30 14:31 ` Andrew F. Davis 2019-01-18 18:37 ` [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes Liam Mark 2019-01-18 18:37 ` Liam Mark 2019-01-18 20:48 ` Laura Abbott 2019-01-18 21:32 ` Liam Mark 2019-01-18 22:45 ` Laura Abbott 2019-01-18 22:45 ` Laura Abbott 2019-01-19 10:25 ` Christoph Hellwig 2019-01-19 10:25 ` Christoph Hellwig 2019-01-19 16:50 ` Laura Abbott 2019-01-21 8:30 ` Christoph Hellwig 2019-01-21 19:44 ` Liam Mark 2019-01-21 19:49 ` Andrew F. Davis 2019-01-21 19:49 ` Andrew F. Davis 2019-01-21 20:20 ` Liam Mark 2019-01-21 20:24 ` Andrew F. Davis 2019-01-21 20:24 ` Andrew F. Davis 2019-01-21 22:18 ` Liam Mark 2019-01-22 15:42 ` Andrew F. Davis 2019-01-22 15:42 ` Andrew F. Davis 2019-01-22 22:47 ` Liam Mark 2019-01-22 22:47 ` Liam Mark 2019-01-21 21:30 ` Christoph Hellwig 2019-01-21 22:14 ` Liam Mark 2019-01-21 22:14 ` Liam Mark 2019-01-21 21:29 ` Christoph Hellwig 2019-01-21 21:29 ` Christoph Hellwig 2019-01-21 22:12 ` Liam Mark 2019-01-21 22:12 ` Liam Mark 2019-01-22 16:06 ` Andrew F. Davis [this message] 2019-01-22 16:06 ` Andrew F. Davis 2019-01-22 22:50 ` Liam Mark 2019-01-18 18:37 ` [PATCH 4/4] staging: android: ion: Support " Liam Mark 2019-01-18 18:37 ` Liam Mark 2019-01-21 12:19 ` Brian Starkey 2019-01-21 12:19 ` Brian Starkey 2019-01-22 22:37 ` Liam Mark
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=8d87ffa0-0710-fc82-ef87-50843fe3a4ee@ti.com \ --to=afd@ti.com \ --cc=arve@android.com \ --cc=christian@brauner.io \ --cc=devel@driverdev.osuosl.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=hch@infradead.org \ --cc=joel@joelfernandes.org \ --cc=john.stultz@linaro.org \ --cc=labbott@redhat.com \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lmark@codeaurora.org \ --cc=maco@android.com \ --cc=sumit.semwal@linaro.org \ --cc=tkjos@android.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: linkBe 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.