From: Vince Hsu <vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Alexandre Courbot
<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Terje Bergstrom
<tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: "nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 3/6] mmu: map small pages into big pages(s) by IOMMU if possible
Date: Mon, 20 Apr 2015 19:51:25 +0800 [thread overview]
Message-ID: <5534E83D.80304@nvidia.com> (raw)
In-Reply-To: <CAAVeFuKc1szojynHrGM9TJrJsTK0RjRiO7i7uwxoVPAW=tZJrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 04/20/2015 03:49 PM, Alexandre Courbot wrote:
> On Sat, Apr 18, 2015 at 12:37 AM, Terje Bergstrom <tbergstrom@nvidia.com> wrote:
>> On 04/17/2015 02:11 AM, Alexandre Courbot wrote:
>>> Tracking the PDE and PTE of each memory chunk can probably be avoided
>>> if you change your unmapping strategy. Currently you are going through
>>> the list of nvkm_vm_bp_list, but you know your PDE and PTE are always
>>> going to be adjacent, since a nvkm_vma represents a contiguous block
>>> in the GPU VA. So when unmapping, you can simply check for each PTE
>>> entry whether the IOMMU bit is set, and unmap from the IOMMU space
>>> after unmapping from the GPU VA space, in a loop similar to that of
>>> nvkm_vm_unmap_at().
>>>
>>> Then we only need priv. You are keeping the nvkm_mm_node of the IOMMU
>>> space into it, and you need it to free the IOMMU VA space. If only we
>>> could find another way to store it, we could get rid of the whole
>>> structure and associated list_head in nvkm_vma...
>>>
>>> I need to give it some more thoughts, and we will probably need to
>>> change a few things in base.c to make the hooks more flexible, so
>>> please give me some more time to think about it. :) I just wanted to
>>> share my thoughts so far in case this puts you on track.
>> The way you described it would make GPU MMU and IOMMU mappings 1:1. So when
>> we map a buffer to GPU MMU, we always map page by page the buffer also to
>> IOMMU. There are disadvantages here.
>>
>> IOMMU addresses are global, and uses in the GPU caches. When a buffer is
>> mapped multiple times to different graphics contexts, we want to avoid cache
>> aliasing by mapping the buffer only once to IOMMU. We also want to unmap the
>> buffer from IOMMU only once after all the instances of the buffer have been
>> unmapped, or only when the buffer is actually freed to cache IOMMU mappings.
>>
>> Doing IOMMU mapping for the whole buffer with dma_map_sg is also faster than
>> mapping page by page, because you can do only one TLB invalidate in the end
>> of the loop instead of after every page if you use dma_map_single.
>>
>> All of these would talk for having IOMMU and GMMU mapping loops separate.
>> This patch set does not implement both the advantages above, but your
>> suggestion would take us further away from that than Vince's version.
> Aha, looks like both Vince and I overlooked this point. So IIUC we
> would need to make sure a GPU buffer is only ever mapped once by the
> IOMMU. This means we either need to preemptively entilery map it at
> some point and just keep a reference count, or keep track of which
> 128k ranges are already mapped (again, with a reference count to know
> when to unmap them).
>
> First solution is tempting because it is simpler, but surely there is
> something wrong with it?
We can maintain a list in mmu/gk20a.c and use the first small page's
address as a search index for the corresponding 128K page.
e.g.
--- a/drm/nouveau/nvkm/subdev/mmu/gk20a.c
+++ b/drm/nouveau/nvkm/subdev/mmu/gk20a.c
@@ -38,6 +38,8 @@ struct gk20a_mmu_priv {
struct gk20a_mmu_iommu_mapping {
struct nvkm_mm_node *node;
u64 iova;
+ u64 index;
+ struct list_head head;
};
extern const u8 gf100_pte_storage_type_map[256];
@@ -79,6 +81,14 @@ gk20a_vm_map_iommu(struct nvkm_vma *vma, struct
nvkm_gpuobj *pgt,
plat = nv_device_to_platform(nv_device(&mmu->base));
+ list_for_each_entry(mapping, mapping_list, head) {
+ if (mapping->index == *list) {
+ mapping->refcnt++;
+ *priv = mapping;
+ return;
+ }
+ }
+
*priv = kzalloc(sizeof(struct gk20a_mmu_iommu_mapping),
GFP_KERNEL);
if (!*priv)
return;
@@ -95,6 +105,8 @@ gk20a_vm_map_iommu(struct nvkm_vma *vma, struct
nvkm_gpuobj *pgt,
if (ret)
return;
+ priv->index = *list;
+
for (i = 0; i < npages; i++, list++) {
ret = iommu_map(plat->gpu->iommu.domain,
(node->offset + i) << PAGE_SHIFT,
@@ -117,6 +129,7 @@ gk20a_vm_map_iommu(struct nvkm_vma *vma, struct
nvkm_gpuobj *pgt,
p = *priv;
p->node = node;
p->iova = node->offset << PAGE_SHIFT;
+ list_add_tail(&priv->head, mapping_list);
}
Thanks,
Vince
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
next prev parent reply other threads:[~2015-04-20 11:51 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 11:06 [PATCH 0/6] map big page by platform IOMMU Vince Hsu
[not found] ` <1429182379-31964-1-git-send-email-vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-16 11:06 ` [PATCH 1/6] platform: specify the IOMMU physical translation bit Vince Hsu
[not found] ` <1429182379-31964-2-git-send-email-vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-16 20:41 ` Terje Bergstrom
[not found] ` <55301E65.5000705-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-17 2:22 ` Vince Hsu
2015-04-17 6:26 ` Alexandre Courbot
[not found] ` <CAAVeFuL10UidtE4_Y2mYEYpWjDqXn-FQF3zJQv2eQDqg_QTJ1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-17 7:07 ` Vince Hsu
2015-04-17 15:10 ` Terje Bergstrom
[not found] ` <55312257.8000606-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-20 7:37 ` Alexandre Courbot
[not found] ` <CAAVeFuKSY9AvtmjkVY7CApMex3Gq5L5cQ=suaERY5-gtAYai6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-20 16:35 ` Terje Bergstrom
2015-04-16 11:06 ` [PATCH 2/6] instmem/gk20a: refer to " Vince Hsu
[not found] ` <1429182379-31964-3-git-send-email-vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-17 6:26 ` Alexandre Courbot
[not found] ` <CAAVeFuJqWuQeH1tbAdkVpocBAjq52GPv_O_yxd0X+7gSHjCoJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-17 7:19 ` Vince Hsu
[not found] ` <5530B3F7.3000000-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-17 7:40 ` Alexandre Courbot
2015-04-17 15:14 ` Terje Bergstrom
[not found] ` <5531234C.8020806-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-20 7:38 ` Alexandre Courbot
[not found] ` <CAAVeFu+p=FFqMNTYNVo1DKnFWZ88_5osiTbiHQR=wQ6tJhHzBA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-20 16:37 ` Terje Bergstrom
2015-04-16 11:06 ` [PATCH 3/6] mmu: map small pages into big pages(s) by IOMMU if possible Vince Hsu
[not found] ` <1429182379-31964-4-git-send-email-vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-17 9:11 ` Alexandre Courbot
[not found] ` <CAAVeFuLSYGV8ghOQ26ubA9kvWHCPD2y+y_bJMLHv1V1Ab8NOYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-17 15:37 ` Terje Bergstrom
[not found] ` <553128CA.40304-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-20 7:49 ` Alexandre Courbot
[not found] ` <CAAVeFuKc1szojynHrGM9TJrJsTK0RjRiO7i7uwxoVPAW=tZJrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-20 11:51 ` Vince Hsu [this message]
[not found] ` <5534E83D.80304-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-20 11:55 ` Vince Hsu
2015-04-20 16:47 ` Terje Bergstrom
2015-04-16 11:06 ` [PATCH 4/6] drm: enable big page mapping for small pages when IOMMU is available Vince Hsu
[not found] ` <1429182379-31964-5-git-send-email-vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-17 6:26 ` Alexandre Courbot
[not found] ` <CAAVeFu+_zJ4DUwebhzpfA9uJroFEVrOBRqiXUuS9Gk04hVA88A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-17 7:28 ` Vince Hsu
[not found] ` <5530B603.9010703-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-17 7:33 ` Alexandre Courbot
2015-04-17 15:24 ` Terje Bergstrom
2015-04-16 11:06 ` [PATCH 5/6] mmu: gf100: share most of functions with GK20A Vince Hsu
[not found] ` <1429182379-31964-6-git-send-email-vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-17 6:27 ` Alexandre Courbot
[not found] ` <CAAVeFuJay4TNdOwEorver+-WiYCLJ21BXcRgCBv1aush_i1wbg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-17 7:30 ` Vince Hsu
2015-04-16 11:06 ` [PATCH 6/6] mmu: gk20a: implement IOMMU mapping for big pages Vince Hsu
[not found] ` <1429182379-31964-7-git-send-email-vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-16 19:31 ` Ilia Mirkin
[not found] ` <CAKb7UvhEuNSYshiP+kt66zHfsmB=Edy+t7HLs2j_+-hvzzkdMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-16 19:55 ` Terje Bergstrom
[not found] ` <553013A4.1020700-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-16 20:01 ` Ilia Mirkin
2015-04-17 6:25 ` [PATCH 0/6] map big page by platform IOMMU Alexandre Courbot
[not found] ` <CAAVeFuJLRo1XYum3FZBhO5=5u63KLUY_tr0wk=TPxWutvCdL8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-17 7:35 ` Vince Hsu
[not found] ` <5530B7D3.60700-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-17 7:37 ` Alexandre Courbot
[not found] ` <CAAVeFuLdr7h29G6_1XGV8kTag=m4Spe_R9Aog38eRs9gAbgdVg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-17 7:42 ` Vince Hsu
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=5534E83D.80304@nvidia.com \
--to=vinceh-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.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 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.