AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Grodzovsky, Andrey" <Andrey.Grodzovsky-5C7GfCeVMHo@public.gmane.org>
To: "Koenig,
	Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>,
	"Liu, Shaoyun" <Shaoyun.Liu-5C7GfCeVMHo@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "Deucher,
	Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
	"Liu, Monk" <Monk.Liu-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 5/5] drm/amdgpu: Refactor GPU reset for XGMI hive case.
Date: Mon, 26 Nov 2018 19:28:00 +0000	[thread overview]
Message-ID: <71b1c9db-68ec-d4bf-d125-1aed69769fc1@amd.com> (raw)
In-Reply-To: <329e176f-ab36-fc79-8646-484975ebb8c3-5C7GfCeVMHo@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 2031 bytes --]


Actually, after looking again at drm_sched_job_timedout  from which the amdgpu_device_gpu_recover will be called I see that we already disconnect all the pending scheduler fences from the HW fence, including
the guilty job. I also see that in drm_sched_job_timedout job_list_lock is released before calling sched->ops->timedout_job and then required after, so new jobs can slip into ring_mirror_list in between.

And also i will end up going over the ring_mirror_list twice, once from amdgpu_device_post_asic_reset and later from drm_sched_job_timedout - this might cause double fence processing.

Isn't it more correct only do the disconnect from HW fence after the schedules have been stopped and connect back before we restart the schedulers (as you pointed out here before)

What I mean is - should we get rid of dma_fence_add/remove_callback logic in drm_sched_job_timedout and do it for each driver in between

scheduler deactivation  and activation back ?

Andrey

On 11/22/2018 02:56 PM, Grodzovsky, Andrey wrote:

Additional to that I would try improve the pre, middle, post handling
towards checking if we made some progress in between.

In other words we stop all schedulers in the pre handling and
disconnect the scheduler fences from the hardware fence like I did in
patch "drm/sched: fix timeout handling v2".

Then before we do the actual reset in the middle handling we check if
the offending job has completed or at least made some progress in the
meantime.


I understand how to check if the job completed - if it's fence already
signaled, but how do I test if the job made 'at least some progress' ?


Good question. Maybe we can somehow query from the hardware the number
of primitives or pixels processed so far and then compare after a moment?


I will check on this later. In the mean while I will update the code
with the proposed per hive locking and I will add the check if the
guilty job completed before ASIC reset skipping the reset if it's did.

Andrey




[-- Attachment #1.2: Type: text/html, Size: 2698 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2018-11-26 19:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-21 18:10 [PATCH 0/5] Add support for XGMI hive reset Andrey Grodzovsky
     [not found] ` <1542823821-15631-1-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2018-11-21 18:10   ` [PATCH 1/5] drm/amdgpu/psp: Add mode 0 reset function Andrey Grodzovsky
     [not found]     ` <1542823821-15631-2-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2018-11-21 19:22       ` Alex Deucher
2018-11-21 18:10   ` [PATCH 2/5] drm/amdgpu/psp: Enable mode 0 reset for XGMI Andrey Grodzovsky
     [not found]     ` <1542823821-15631-3-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2018-11-21 19:23       ` Alex Deucher
2018-11-21 18:10   ` [PATCH 3/5] drm/amdgpu: Refactor amdgpu_xgmi_add_device Andrey Grodzovsky
     [not found]     ` <1542823821-15631-4-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2018-11-21 19:29       ` Alex Deucher
     [not found]         ` <CADnq5_MSpxAXsdwh+NzXCrOGVVo3gog9FjdzRNaX9ZhwuatmKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-11-21 19:36           ` Grodzovsky, Andrey
     [not found]             ` <aa7ee809-8f1f-c4de-c674-4b11f77b70f3-5C7GfCeVMHo@public.gmane.org>
2018-11-21 19:38               ` Alex Deucher
2018-11-21 18:10   ` [PATCH 4/5] drm/amdgpu: Expose hive adev list and xgmi_mutex Andrey Grodzovsky
     [not found]     ` <1542823821-15631-5-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2018-11-21 19:45       ` Alex Deucher
2018-11-21 18:10   ` [PATCH 5/5] drm/amdgpu: Refactor GPU reset for XGMI hive case Andrey Grodzovsky
     [not found]     ` <1542823821-15631-6-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2018-11-21 19:45       ` Alex Deucher
2018-11-21 20:49       ` Liu, Shaoyun
     [not found]         ` <ef758cf9-9e27-9807-4e25-47148782249e-5C7GfCeVMHo@public.gmane.org>
2018-11-21 22:02           ` Grodzovsky, Andrey
     [not found]             ` <5f257299-4833-82b7-83ec-75bf02c4e441-5C7GfCeVMHo@public.gmane.org>
2018-11-22 11:16               ` Christian König
     [not found]                 ` <8e9f51a4-7f0a-c435-c507-34eea96e0b08-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-11-22 15:44                   ` Grodzovsky, Andrey
     [not found]                     ` <9e016b33-6c94-b1cb-cdcd-b68b91436e90-5C7GfCeVMHo@public.gmane.org>
2018-11-22 19:03                       ` Christian König
     [not found]                         ` <0f048ac9-1247-8d87-d8c8-5a249e24cdcb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-11-22 19:56                           ` Grodzovsky, Andrey
     [not found]                             ` <329e176f-ab36-fc79-8646-484975ebb8c3-5C7GfCeVMHo@public.gmane.org>
2018-11-26 19:28                               ` Grodzovsky, Andrey [this message]
     [not found]                                 ` <71b1c9db-68ec-d4bf-d125-1aed69769fc1-5C7GfCeVMHo@public.gmane.org>
2018-11-26 19:34                                   ` Christian König

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=71b1c9db-68ec-d4bf-d125-1aed69769fc1@amd.com \
    --to=andrey.grodzovsky-5c7gfcevmho@public.gmane.org \
    --cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
    --cc=Christian.Koenig-5C7GfCeVMHo@public.gmane.org \
    --cc=Monk.Liu-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