From: Nicolin Chen <nicoleotsuka@gmail.com>
To: "Koenig, Christian" <Christian.Koenig@amd.com>
Cc: "sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] dma-buf: refcount the attachment for cache_sgt_mapping
Date: Wed, 12 Jun 2019 01:02:14 -0700 [thread overview]
Message-ID: <20190612080214.GA8876@Asurada> (raw)
In-Reply-To: <261b46c7-0c5e-4268-619d-f8381fbc3aeb@amd.com>
Hi Christian,
Thanks for the quick reply.
On Wed, Jun 12, 2019 at 07:45:38AM +0000, Koenig, Christian wrote:
> Am 12.06.19 um 03:22 schrieb Nicolin Chen:
> > Commit f13e143e7444 ("dma-buf: start caching of sg_table objects v2")
> > added a support of caching the sgt pointer into an attach pointer to
> > let users reuse the sgt pointer without another mapping. However, it
> > might not totally work as most of dma-buf callers are doing attach()
> > and map_attachment() back-to-back, using drm_prime.c for example:
> > drm_gem_prime_import_dev() {
> > attach = dma_buf_attach() {
> > /* Allocating a new attach */
> > attach = kzalloc();
> > /* .... */
> > return attach;
> > }
> > dma_buf_map_attachment(attach, direction) {
> > /* attach->sgt would be always empty as attach is new */
> > if (attach->sgt) {
> > /* Reuse attach->sgt */
> > }
> > /* Otherwise, map it */
> > attach->sgt = map();
> > }
> > }
> >
> > So, for a cache_sgt_mapping use case, it would need to get the same
> > attachment pointer in order to reuse its sgt pointer. So this patch
> > adds a refcount to the attach() function and lets it search for the
> > existing attach pointer by matching the dev pointer.
>
> I don't think that this is a good idea.
>
> We use sgt caching as workaround for locking order problems and want to
> remove it again in the long term.
Oh. I thought it was for a performance improving purpose. It may
be a misunderstanding then.
> So what is the actual use case of this?
We have some similar downstream changes at dma_buf to reduce the
overhead from multiple clients of the same device doing attach()
and map_attachment() calls for the same dma_buf.
We haven't used DRM/GRM_PRIME yet but I am also curious would it
benefit DRM also if we reduce this overhead in the dma_buf?
Thanks
Nicolin
next prev parent reply other threads:[~2019-06-12 8:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 1:22 [PATCH] dma-buf: refcount the attachment for cache_sgt_mapping Nicolin Chen
2019-06-12 7:45 ` Koenig, Christian
2019-06-12 8:02 ` Nicolin Chen [this message]
2019-06-12 8:05 ` Koenig, Christian
2019-06-12 8:15 ` Nicolin Chen
2019-06-12 8:20 ` Koenig, Christian
2019-06-12 8:25 ` Nicolin Chen
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=20190612080214.GA8876@Asurada \
--to=nicoleotsuka@gmail.com \
--cc=Christian.Koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@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