All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Jesse Zhang <Jesse.Zhang@amd.com>, amd-gfx@lists.freedesktop.org
Cc: Alexander.Deucher@amd.com, Prike Liang <prike.liang@amd.com>,
	Sunil Khatri <sunil.khatri@amd.com>
Subject: Re: [PATCH 1/3] drm/amdgpu: don't wait for the SPM VMID's jobs under the VMID manager lock
Date: Tue, 20 Oct 2026 13:33:51 +0200	[thread overview]
Message-ID: <20e90363-511b-451b-8523-e07a7d6a960e@amd.com> (raw)
In-Reply-To: <20261020083804.2777099-1-Jesse.Zhang@amd.com>



On 10/20/26 10:37, Jesse Zhang wrote:
> amdgpu_vmid_free_spm() waits for the jobs of the reserved VMID while
> holding the VMID manager lock of the hub, which every VMID grab on the
> hub takes as well. Freeing the reservation, by UNRESERVE_VMID or when
> the VM is destroyed, so stalls the kernel queue submissions of every
> process on the GFXHUB until those jobs completed, or until the job
> timeout if one of them hangs. A full GPU reset even deadlocks, since
> amdgpu_vmid_reset_all() needs the lock before the scheduler is started
> again to signal the jobs.
> 
> On navi31, with a GFX job of the reserving process that waits for 1s,
> an unrelated process' SDMA NOP takes 0.8s instead of no time when the
> VMID gets unreserved meanwhile.
> 
> Nothing adds to the active fences of the VMID once it's no longer the
> VM's reserved one, so drop the lock while waiting for them. Keep the
> VMID reserved until then, so that nobody else can bind it before.
> 
> Fixes: 9b47649cabf4 ("drm/amdgpu: bind the SPM VMID's page table to the reserving VM")
> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 19 ++++++++++---------
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
> index 1482fc031d44..d19bbcf25765 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
> @@ -645,17 +645,18 @@ void amdgpu_vmid_free_spm(struct amdgpu_device *adev, struct amdgpu_vm *vm,
>  
>  	mutex_lock(&id_mgr->lock);
>  	id = vm->reserved_vmid[vmhub];
> -	if (id) {
> -		vm->reserved_vmid[vmhub] = NULL;
> -		id_mgr->reserved_vmid = false;
> +	vm->reserved_vmid[vmhub] = NULL;
> +	mutex_unlock(&id_mgr->lock);
> +	if (!id)
> +		return;
>  
> -		/* Only for kernel queues and kfd/userqueues by pass that */
> -		amdgpu_sync_wait(&id->active, false);
> +	amdgpu_sync_wait(&id->active, false);

Accessing id->active without holding the lock is a pretty big no-go as well.

We should probably rather move the amdgpu_sync_wait into the caller of the function and wait for vm->root.bo->tbo.base.resv instead.

That should have the same effect, but we don't need to hold the VMID lock for that.

Regards,
Christian.

>  
> -		if (adev->vm_manager.spm_vmid && adev->gfxhub.funcs)
> -			amdgpu_gmc_bind_vmid(adev, AMDGPU_GFXHUB(0),
> -					     adev->vm_manager.spm_vmid, 0);
> -	}
> +	mutex_lock(&id_mgr->lock);
> +	if (adev->vm_manager.spm_vmid && adev->gfxhub.funcs)
> +		amdgpu_gmc_bind_vmid(adev, AMDGPU_GFXHUB(0),
> +				     adev->vm_manager.spm_vmid, 0);
> +	id_mgr->reserved_vmid = false;
>  	mutex_unlock(&id_mgr->lock);
>  }
>  


      parent reply	other threads:[~2026-10-20 11:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20  8:37 [PATCH 1/3] drm/amdgpu: don't wait for the SPM VMID's jobs under the VMID manager lock Jesse Zhang
2026-10-20  8:37 ` [PATCH 2/3] drm/amdgpu: keep the CS user fence BO in GTT Jesse Zhang
2026-10-20  8:37 ` [PATCH 3/3] drm/amdgpu: reject CS chunks too large for kvmalloc() Jesse Zhang
2026-10-20 11:36   ` Christian König
2026-10-20 11:33 ` Christian König [this message]

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=20e90363-511b-451b-8523-e07a7d6a960e@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Jesse.Zhang@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=prike.liang@amd.com \
    --cc=sunil.khatri@amd.com \
    /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.