From: "Kuehling, Felix" <Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>
To: "Liu, Shaoyun" <Shaoyun.Liu-5C7GfCeVMHo@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH] drm/amdgpu: Add preferred_domain check when determine XGMI state
Date: Thu, 28 Mar 2019 19:58:54 +0000 [thread overview]
Message-ID: <48ecf63e-12e1-70af-44d5-9c579dd1f1dc@amd.com> (raw)
In-Reply-To: <5187cc22-bf83-9617-d9df-c5ab1bca5735-5C7GfCeVMHo@public.gmane.org>
On 2019-03-28 3:47 p.m., Liu, Shaoyun wrote:
> I think we only care about the context device (adev) and the real device
> this bo been allocated(robj->tbo.bdev). The bo_va or base don't have
> the device pointer directly, it have a pointer to bo which should be
> the same as robj here. We can move the same_hive check out of the
> loop .
That doesn't make sense. The "same hive" check only makes sense if one
of the devices is the one where the memory is physically located
(robj->tbo.bdev), and the other one is where the memory is accessed
from. That only makes sense inside the loop. The amdgpu_vm_bo_base
should tell you the device that's mapping and potentially accessing the
memory over XGMI. You could get it like this:
mapping_adev = base->vm->root.base.bo->tbo.bdev;
Regards,
Felix
>
> Regards
>
> shaoyun.liu
>
>
> On 2019-03-28 3:18 p.m., Kuehling, Felix wrote:
>> On 2019-03-28 1:55 p.m., Liu, Shaoyun wrote:
>>> Avoid unnecessary XGMI hight pstate trigger when mapping none-vram memory for peer device
>>>
>>> Change-Id: I1881deff3da19f1f4b58d5765db03a590092a5b2
>>> Signed-off-by: shaoyunl <shaoyun.liu@amd.com>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 13 +++++++++++++
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
>>> 2 files changed, 15 insertions(+), 1 deletion(-)
>>> I think we only care about the context device (adev) and the real device this bo been allocated ,
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> index 9ee8d7a..82dc2b6 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> @@ -31,6 +31,7 @@
>>> #include <drm/amdgpu_drm.h>
>>> #include "amdgpu.h"
>>> #include "amdgpu_display.h"
>>> +#include "amdgpu_xgmi.h"
>>>
>>> void amdgpu_gem_object_free(struct drm_gem_object *gobj)
>>> {
>>> @@ -666,6 +667,8 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
>>> struct amdgpu_device *adev = dev->dev_private;
>>> struct drm_amdgpu_gem_op *args = data;
>>> struct drm_gem_object *gobj;
>>> + struct amdgpu_vm_bo_base *base;
>>> + struct amdgpu_bo_va *bo_va;
>>> struct amdgpu_bo *robj;
>>> int r;
>>>
>>> @@ -704,6 +707,16 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
>>> amdgpu_bo_unreserve(robj);
>>> break;
>>> }
>>> + for (base = robj->vm_bo; base; base = base->next) {
>>> + bo_va = container_of(base, struct amdgpu_bo_va, base);
>>> + if (bo_va &&
>>> + amdgpu_xgmi_same_hive(adev,amdgpu_ttm_adev(robj->tbo.bdev))) {
>> adev and robj->tbo.bdev are the same in each loop iteration. Shouldn't
>> we get one of the devices from the bo_va or amdgpu_vm_bo_base?
>>
>> Regards,
>> Felix
>>
>>
>>> + r = -EINVAL;
>>> + amdgpu_bo_unreserve(robj);
>>> + goto out;
>>> + }
>>> + }
>>> +
>>> robj->preferred_domains = args->value & (AMDGPU_GEM_DOMAIN_VRAM |
>>> AMDGPU_GEM_DOMAIN_GTT |
>>> AMDGPU_GEM_DOMAIN_CPU);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> index 3d221f0..eb242a1 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> @@ -2025,7 +2025,8 @@ struct amdgpu_bo_va *amdgpu_vm_bo_add(struct amdgpu_device *adev,
>>> INIT_LIST_HEAD(&bo_va->valids);
>>> INIT_LIST_HEAD(&bo_va->invalids);
>>>
>>> - if (bo && amdgpu_xgmi_same_hive(adev, amdgpu_ttm_adev(bo->tbo.bdev))) {
>>> + if (bo && amdgpu_xgmi_same_hive(adev, amdgpu_ttm_adev(bo->tbo.bdev)) &&
>>> + (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM)) {
>>> bo_va->is_xgmi = true;
>>> mutex_lock(&adev->vm_manager.lock_pstate);
>>> /* Power up XGMI if it can be potentially used */
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-03-28 19:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-28 17:55 [PATCH] drm/amdgpu: Add preferred_domain check when determine XGMI state Liu, Shaoyun
[not found] ` <1553795695-6065-1-git-send-email-shaoyun.liu-5C7GfCeVMHo@public.gmane.org>
2019-03-28 19:18 ` Kuehling, Felix
[not found] ` <5744d324-0e7b-a19d-f4b5-a5242f664e8e-5C7GfCeVMHo@public.gmane.org>
2019-03-28 19:47 ` Liu, Shaoyun
[not found] ` <5187cc22-bf83-9617-d9df-c5ab1bca5735-5C7GfCeVMHo@public.gmane.org>
2019-03-28 19:58 ` Kuehling, Felix [this message]
2019-03-29 10:47 ` Christian König
-- strict thread matches above, loose matches on Subject: below --
2019-03-28 20:38 Liu, Shaoyun
[not found] ` <1553805488-15372-1-git-send-email-shaoyun.liu-5C7GfCeVMHo@public.gmane.org>
2019-03-28 20:39 ` Kuehling, Felix
[not found] ` <a5df1503-edc9-f744-c340-4b45b243f29b-5C7GfCeVMHo@public.gmane.org>
2019-03-29 10:50 ` Christian König
2019-03-28 20:29 Liu, Shaoyun
2019-03-28 20:27 Liu, Shaoyun
2019-03-28 19:53 Liu, Shaoyun
2019-03-26 20:35 Liu, Shaoyun
[not found] ` <1553632516-23346-1-git-send-email-shaoyun.liu-5C7GfCeVMHo@public.gmane.org>
2019-03-27 7:41 ` Christian König
[not found] ` <c42cc872-cddf-01b9-b46e-b2084f8a1bc3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-27 15:22 ` Liu, Shaoyun
[not found] ` <5d6e562d-012b-f22b-7ec9-2fdf33a9319d-5C7GfCeVMHo@public.gmane.org>
2019-03-27 15:30 ` Koenig, Christian
[not found] ` <3e28a7df-4165-4bde-8a2e-926453ceb1d1-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
2019-03-27 15:34 ` Liu, Shaoyun
[not found] ` <fd7f4b68-26c2-d0ea-b254-fbc61a0d3956-5C7GfCeVMHo@public.gmane.org>
2019-03-27 15:39 ` Koenig, Christian
[not found] ` <68f7ccfa-646e-492f-bdd7-b24f2e2029da-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
2019-03-27 15:43 ` Liu, Shaoyun
[not found] ` <7a3199ec-c851-6b50-7e1f-b467e5e78d13-5C7GfCeVMHo@public.gmane.org>
2019-03-27 15:44 ` Koenig, Christian
2019-03-27 15:52 ` Kuehling, Felix
[not found] ` <5e7addf1-61f7-a0f9-a709-5039ba1de840-5C7GfCeVMHo@public.gmane.org>
2019-03-27 16:24 ` Liu, Shaoyun
2019-03-26 18:54 Liu, Shaoyun
[not found] ` <1553626381-23351-1-git-send-email-shaoyun.liu-5C7GfCeVMHo@public.gmane.org>
2019-03-26 19:12 ` Christian König
2019-03-26 20:02 ` Kuehling, Felix
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=48ecf63e-12e1-70af-44d5-9c579dd1f1dc@amd.com \
--to=felix.kuehling-5c7gfcevmho@public.gmane.org \
--cc=Shaoyun.Liu-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox