[AMD Official Use Only - General]
Can we just add kref for entity?
Or just collect such job time usage somewhere else?
-Original Message-
From: Pan, Xinhui
Sent: Thursday, August 17, 2023 1:05 PM
To: amd-...@lists.freedesktop.org
Cc: Tuikov, Luben ; airl...@gmail.com;
dri-devel
[AMD Official Use Only - General]
comments line.
发件人: Koenig, Christian
发送时间: 2022年11月29日 20:07
收件人: Pan, Xinhui; amd-...@lists.freedesktop.org
抄送: dan...@ffwll.ch; matthew.a...@intel.com; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org
[AMD Official Use Only - General]
comments inline.
发件人: Koenig, Christian
发送时间: 2022年11月29日 19:32
收件人: Pan, Xinhui; amd-...@lists.freedesktop.org
抄送: dan...@ffwll.ch; matthew.a...@intel.com; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org
goto err_free;
thanks
xinhui
____________
发件人: Pan, Xinhui
发送时间: 2022年11月29日 18:56
收件人: amd-...@lists.freedesktop.org
抄送: dan...@ffwll.ch; matthew.a...@intel.com; Koenig, Christian;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Paneer Se
[AMD Official Use Only - General]
Hi Arun,
Thanks for your reply. comments are inline.
发件人: Paneer Selvam, Arunpravin
发送时间: 2022年11月29日 1:09
收件人: Pan, Xinhui; amd-...@lists.freedesktop.org
抄送: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org
[AMD Official Use Only]
Looks good to me. Thanks
-Original Message-
From: Christian König
Sent: Thursday, December 2, 2021 6:38 PM
To: Pan, Xinhui ; dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/ttm: fix ttm_bo_swapout
Commit 7120a447c7fe ("drm/ttm: Double check mem_type
Christian
发送时间: 2021年11月9日 21:18
收件人: Pan, Xinhui; amd-...@lists.freedesktop.org
抄送: dri-devel@lists.freedesktop.org
主题: Re: 回复: 回复: [PATCH] drm/ttm: Put BO in its memory manager's lru list
Exactly that's the reason why we should have the double check in TTM
I've mentioned in t
ist is on vram domain) to sMem.
发件人: Pan, Xinhui
发送时间: 2021年11月9日 21:05
收件人: Koenig, Christian; amd-...@lists.freedesktop.org
抄送: dri-devel@lists.freedesktop.org
主题: 回复: 回复: [PATCH] drm/ttm: Put BO in its memory manager's lru list
Yes, a stable tag i
omain_start(adev, mem->mem_type) +
209 mm_cur->start;
210 return 0;
211 }
line 208, *addr is zero. So when amdgpu_copy_buffer submit job with such addr,
page fault happens.
发件人: Koenig, Christian
, Christian
发送时间: 2021年11月9日 20:20
收件人: Pan, Xinhui; amd-...@lists.freedesktop.org
抄送: dri-devel@lists.freedesktop.org
主题: Re: [PATCH] drm/ttm: Put BO in its memory manager's lru list
Am 09.11.21 um 12:19 schrieb xinhui pan:
> After we move BO to a new memory region, we should put it to
> the
: Christian König
发送时间: 2021年9月13日 14:35
收件人: Pan, Xinhui; amd-...@lists.freedesktop.org
抄送: Koenig, Christian; dan...@ffwll.ch; dri-devel@lists.freedesktop.org; Chen,
Guchun
主题: Re: [RFC PATCH] drm/ttm: Try to check if new ttm man out of bounds during
compile
Am 13.09.21 um 05:36 schrieb
; Koenig,
Christian ; Pan, Xinhui ;
Deucher, Alexander
Cc: Chen, Guchun ; Shi, Leslie
Subject: [PATCH] drm/ttm: add a BUG_ON in ttm_set_driver_manager when array
bounds
Vendor will define their own memory types on top of TTM_PL_PRIV,
but call ttm_set_driver_manager directly without checking mem_type
[AMD Official Use Only]
It is the internal staging drm-next.
-Original Message-
From: Koenig, Christian
Sent: 2021年9月6日 19:26
To: Pan, Xinhui ; amd-...@lists.freedesktop.org
Cc: Deucher, Alexander ; che...@uniontech.com;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 1/2] drm
> 2021年9月6日 17:04，Christian König 写道：
>
>
>
> Am 06.09.21 um 03:12 schrieb xinhui pan:
>> A long time ago, someone reports system got hung during memory test.
>> In recent days, I am trying to look for or understand the potential
>> deadlock in ttm/amdgpu code.
>>
>> This patchset aims to fi
[AMD Official Use Only]
Like vce/vcn does, visible VRAM is OK for ib test.
While commit a11d9ff3ebe0 ("drm/amdgpu: use GTT for
uvd_get_create/destory_msg") says VRAM is not mapped correctly in his
platform which is likely an arm64.
So lets change back to use VRAM on x86_64 platform.
Signed-off-b
[AMD Official Use Only]
The ret value might be -EBUSY, caller will think lru lock is still
locked but actually NOT. So return -ENOSPC instead. Otherwise we hit
list corruption.
ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0,
caller(ttm_tt_populate -> ttm_global_swapout ->ttm
[AMD Official Use Only]
A long time ago, someone reports system got hung during memory test.
In recent days, I am trying to look for or understand the potential
deadlock in ttm/amdgpu code.
This patchset aims to fix the deadlock during ttm populate.
TTM has a parameter called pages_limit, when a
在 2021/9/3 15:04，“Koenig, Christian” 写入:
Am 03.09.21 um 08:49 schrieb Pan, Xinhui:
> Like vce/vcn does, visible VRAM is ok for ib test.
> And in ib test stage, VRAM is sufficient.
NAK, that won't work for older hw generations (e.g. SI, maybe CIK as
well) wh
Like vce/vcn does, visible VRAM is ok for ib test.
And in ib test stage, VRAM is sufficient.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/am
The ret value might be -EBUSY, caller will think lru lock is still
locked but actually NOT. So return -ENOSPC instead. Otherwise we hit
list corruption.
ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0,
caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will
be
A long time ago, someone reports system got hung during memory test.
In recent days, I am trying to look for or understand the potential
deadlock in ttm/amdgpu code.
This patchset aims to fix the deadlock during ttm populate.
TTM has a parameter called pages_limit, when allocated GTT memory
reach
> 2021年6月15日 20:01，Christian König 写道：
>
> Am 15.06.21 um 13:57 schrieb xinhui pan:
>> Amdgpu set SG flag in populate callback. So TTM still count pages in SG
>> BO.
>
> It's probably better to fix this instead. E.g. why does amdgpu modify the SG
> flag during populate and not during initial
[AMD Official Use Only]
Looks good to me.
From: Christian König
Sent: Monday, June 7, 2021 8:52:21 PM
To: dri-devel@lists.freedesktop.org ; Pan,
Xinhui ; Das, Nirmoy ; Huang, Ray
Cc: Thomas Hellström
Subject: Re: [PATCH] drm/ttm: fix deref of bo->ttm with
[AMD Official Use Only]
I just sent out patch below yesterday. swapping unpopulated bo is useless
indeed.
[RFC PATCH 2/2] drm/ttm: skip swapout when ttm has no backend page.
发件人: Christian König
发送时间: 2021年5月20日 14:39
收件人: Pan, Xinhui; Kuehling, Felix
I just sent out patch below yesterday. swapping unpopulated bo is useless
indeed.
[RFC PATCH 2/2] drm/ttm: skip swapout when ttm has no backend page.
König; Pan, Xinhui; amd-...@lists.freedesktop.org
抄送: Deucher, Alexander; dan...@ffwll.ch; Koenig, Christian;
dri-devel@lists.freedesktop.org
主题: Re: 回复: [RFC PATCH 1/2] drm/amdgpu: Fix memory corruption due to swapout
and swapin
Looks like we're creating the userptr BO as ttm_bo_type_devi
as TTM_PAGE_FLAG_SWAPPED is set.
Now here is the problem, we swapin data to ttm bakend memory from swap storage.
That just causes the memory been overwritten.
发件人: Christian König
发送时间: 2021年5月19日 18:01
收件人: Pan, Xinhui; Kuehling, Felix; amd-...@lists.freedesktop.org
PRIORITY; ++i) {
- list_for_each_entry(bo, &glob->swap_lru[i], swap) {
[snip]
+ for (i = TTM_PL_SYSTEM; i < TTM_NUM_MEM_TYPES; ++i) {
+ for (j = 0; j < TTM_MAX_BO_PRIORITY; ++j) {
________
发件人: Pan, Xinhui
发送时间: 2021
Chris' patch as I think it desnt help. Or I can have a
try later.
发件人: Kuehling, Felix
发送时间: 2021年5月19日 11:29
收件人: Pan, Xinhui; amd-...@lists.freedesktop.org
抄送: Deucher, Alexander; Koenig, Christian; dri-devel@lists.freedesktop.org;
dan...@ffwll.ch
主
Memory
TEST_F(KFDMemoryTest, MemoryAlloc) {
TEST_START(TESTPROFILE_RUNALL)
--
2.25.1
____________
发件人: Pan, Xinhui
发送时间: 2021年5月19日 10:28
收件人: amd-...@lists.freedesktop.org
抄送: Kuehling, Felix; Deucher, Alexander; Koenig, Christian;
dri-devel@lists.freedeskt
_
发件人: Yu Kuai
发送时间: 2021年5月17日 16:16
收件人: Deucher, Alexander; Koenig, Christian; Pan, Xinhui; airl...@linux.ie;
dan...@ffwll.ch
抄送: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org; yuku...@huawei.com; yi.zh...@huawei.com
主题: [PATCH] drm/amdgp
> 2020年9月2日 22:50，Tuikov, Luben 写道：
>
> On 2020-09-02 00:43, Pan, Xinhui wrote:
>>
>>
>>> 2020年9月2日 11:46，Tuikov, Luben 写道：
>>>
>>> On 2020-09-01 21:42, Pan, Xinhui wrote:
>>>> If you take a look at the below function, you s
> 2020年9月2日 11:46，Tuikov, Luben 写道：
>
> On 2020-09-01 21:42, Pan, Xinhui wrote:
>> If you take a look at the below function, you should not use driver's
>> release to free adev. As dev is embedded in adev.
>
> Do you mean "look at the function below"
t;Tuikov, Luben"
日期: 2020年9月2日 星期三 09:07
收件人: "amd-...@lists.freedesktop.org" ,
"dri-devel@lists.freedesktop.org"
抄送: "Deucher, Alexander" , Daniel Vetter
, "Pan, Xinhui" , "Tuikov, Luben"
主题: [PATCH 0/3] Use implicit kref infra
Use
other hand you are right that cond_resched() has the advantage that we
> could spend more time on cleaning up old BOs if there is nothing else for the
> CPU TODO.
>
> Regards,
> Christian.
>
> Am 09.04.20 um 16:24 schrieb Pan, Xinhui:
>> https://elixir.bootlin.com/l
https://elixir.bootlin.com/linux/latest/source/mm/slab.c#L4026
This is another example of the usage of cond_sched.
From: Pan, Xinhui
Sent: Thursday, April 9, 2020 10:11:08 PM
To: Lucas Stach ; amd-...@lists.freedesktop.org
; Koenig, Christian
Cc: dri-devel
I think it doesn't matter if workitem schedule out. Even we did not schedule
out, the workqueue itself will schedule out later.
So it did not break anything with this patch I think.
From: Pan, Xinhui
Sent: Thursday, April 9, 2020 10:07:09 PM
To: Lucas Stach
From: Koenig, Christian
Sent: Thursday, April 9, 2020 9:38:24 PM
To: Lucas Stach ; Pan, Xinhui ;
amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete
worker
Am 09.04.20 um 15:25 schrieb Lucas Stach
> 2020年2月28日 13:45，panxinhui 写道：
>
>
>
>> 2020年2月26日 03:11，Koenig, Christian 写道：
>>
>> Am 25.02.20 um 18:23 schrieb Daniel Vetter:
>>> On Sun, Feb 23, 2020 at 01:04:15PM +0100, Christian König wrote:
>>>> Am 23.02.20 um 12:56 schrieb P
> 2020年2月26日 03:11，Koenig, Christian 写道：
>
> Am 25.02.20 um 18:23 schrieb Daniel Vetter:
>> On Sun, Feb 23, 2020 at 01:04:15PM +0100, Christian König wrote:
>>> Am 23.02.20 um 12:56 schrieb Pan, Xinhui:
>>>> If shared fence list is not empty, even we want
> 2020年2月23日 20:04，Koenig, Christian 写道：
>
> Am 23.02.20 um 12:56 schrieb Pan, Xinhui:
>> If shared fence list is not empty, even we want to test all fences, excl
>> fence is ignored.
>> That is abviously wrong, so fix it.
>
> Yeah that is a known issue and
If shared fence list is not empty, even we want to test all fences, excl fence
is ignored.
That is abviously wrong, so fix it.
Signed-off-by: xinhui pan
---
change from v1:
init left correctly
---
drivers/dma-buf/dma-resv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --
sorry, paste a wrong patch. will send out v2.
> 2020年2月23日 19:56，Pan, Xinhui 写道：
>
> If shared fence list is not empty, even we want to test all fences, excl
> fence is ignored.
> That is abviously wrong, so fix it.
>
> Signed-off-by: xinhui pan
> ---
> dri
If shared fence list is not empty, even we want to test all fences, excl fence
is ignored.
That is abviously wrong, so fix it.
Signed-off-by: xinhui pan
---
drivers/dma-buf/dma-resv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drive
> 2020年2月13日 18:01，Koenig, Christian 写道：
>
> Am 13.02.20 um 05:11 schrieb Pan, Xinhui:
>>
>>
>>> 2020年2月12日 19:53，Christian König 写道：
>>>
>>> Am 12.02.20 um 07:23 schrieb Pan, Xinhui:
>>>>> 2020年2月11日 23:43，Christian König 写道：
> 2020年2月12日 19:53，Christian König 写道：
>
> Am 12.02.20 um 07:23 schrieb Pan, Xinhui:
>>
>>> 2020年2月11日 23:43，Christian König 写道：
>>>
>>> When non-imported BOs are resurrected for delayed delete we replace
>>> the dma_resv object to allo
> 2020年2月11日 23:43，Christian König 写道：
>
> When non-imported BOs are resurrected for delayed delete we replace
> the dma_resv object to allow for easy reclaiming of the resources.
>
> v2: move that to ttm_bo_individualize_resv
> v3: add a comment to explain what's going on
>
> Signed-off-by:
> 2020年2月11日 22:14，Daniel Vetter 写道：
>
> On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
>> When non-imported BOs are resurrected for delayed delete we replace
>> the dma_resv object to allow for easy reclaiming of the resources.
>>
>> v2: move that to ttm_bo_individualize_res
Reviewed-by: xinhui pan
> 2020年2月11日 21:43，Christian König 写道：
>
> This patch reworks the whole delayed deletion of BOs which aren't idle.
>
> Instead of having two counters for the BO structure we resurrect the BO
> when we find that a deleted BO is not idle yet.
>
> This has many advantages
[AMD Official Use Only - Internal Distribution Only]
For patch 1/2/3/5/6
Reviewed-by: xinhui pan
From: Christian König
Sent: Monday, February 10, 2020 11:09:01 PM
To: Pan, Xinhui ; amd-...@lists.freedesktop.org
; dri-devel@lists.freedesktop.org
Subject
comments inline
> 2020年2月11日 13:26，Pan, Xinhui 写道：
>
> comments inline.
> [xh]
>
>
>> 2020年2月10日 23:09，Christian König 写道：
>>
>> This patch reworks the whole delayed deletion of BOs which aren't idle.
>>
>> Instead of having two counter
comments inline.
[xh]
> 2020年2月10日 23:09，Christian König 写道：
>
> This patch reworks the whole delayed deletion of BOs which aren't idle.
>
> Instead of having two counters for the BO structure we resurrect the BO
> when we find that a deleted BO is not idle yet.
>
> This has many advantages,
do you mean that something like 1<<65 might be a none zero value?
From: Dan Carpenter
Sent: Saturday, June 8, 2019 5:23:57 PM
To: Deucher, Alexander; Pan, Xinhui
Cc: Koenig, Christian; Zhou, David(ChunMing); David Airlie; Daniel Vetter;
Quan, Evan; Zhu,
etter
发送时间: 2019年5月21日 0:28
收件人: Pan, Xinhui
抄送: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing);
airl...@linux.ie; dan...@ffwll.ch; Quan, Evan; xiaolinkui;
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org
主题: Re: [PATCH] gpu: drm
Daniel, your idea is obviously and totally wrong. There can NOT be more than
one zero-size array in a struct.
Nack for them all.
From: Daniel Vetter on behalf of Daniel Vetter
Sent: Tuesday, May 21, 2019 12:28:07 AM
To: Pan, Xinhui
Cc: Deucher, Alexander
, Christian; Zhou, David(ChunMing);
airl...@linux.ie; dan...@ffwll.ch; Pan, Xinhui; Quan, Evan
Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org; xiaolin...@kylinos.cn
Subject: [PATCH] gpu: drm: use struct_size() in kmalloc()
[CAUTION: External Email]
Use
I am going to apply your fix patch in my branch.
Thanks
xinhui
-Original Message-
From: Nathan Chancellor
Sent: 2019年3月20日 23:45
To: Stephen Hines
Cc: Koenig, Christian ; Pan, Xinhui
; Deucher, Alexander ; Zhou,
David(ChunMing) ; amd-...@lists.freedesktop.org;
dri-devel
ent: 2019年3月20日 8:54
To: Deucher, Alexander ; Koenig, Christian
; Zhou, David(ChunMing) ; Pan,
Xinhui
Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org; clang-built-li...@googlegroups.com
Subject: Clang warning in drivers/gpu/drm/amd/amdgpu/amdgpu_ra
58 matches
Mail list logo
