All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wang, Zhi A" <zhi.a.wang@intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	"Nikula, Jani" <jani.nikula@intel.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Yuan, Hang" <hang.yuan@intel.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	intel-gvt-dev <intel-gvt-dev@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PULL] topic/gvt-ww-lock
Date: Sun, 8 Nov 2020 07:51:57 +0000	[thread overview]
Message-ID: <3ee7e0f7e16746619767b5ed913521b6@intel.com> (raw)
In-Reply-To: <505b138f-46d7-5599-3b41-646508b3bd5b@linux.intel.com>


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

Hi Maarten:

Thanks for the reply. 😊 Have your patches been merged into the drm-intel? (The new i915_gem_object_ggtt_pin() you mentioned in the email). Also, we might go on-demand pin recently in the suspend/resume support. In that case, I guess I need to review my patches again based on the new mechanism. Wrt your concern, my understanding is ww dance is for recording the related locks in a section. When a deadlock happens, we can rewind the locks recorded in a ww dance and rewind them. In the current code, the context is always pinned. So we don’t need to worry about the context as what you said. For preparing_shadow_wa_ctx, the gem object will be newly created whenever scan a execlist context and it will be destroyed when the context is scheduled-out. I think in that case, we need a separate ww dance.
Thanks, Zhi.

-----Original Message-----
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Sent: Wednesday, September 30, 2020 2:55 PM
To: Wang, Zhi A <zhi.a.wang@intel.com>; Joonas Lahtinen <joonas.lahtinen@linux.intel.com>; Nikula, Jani <jani.nikula@intel.com>; intel-gfx <intel-gfx@lists.freedesktop.org>; Yuan, Hang <hang.yuan@intel.com>; Lv, Zhiyuan <zhiyuan.lv@intel.com>; intel-gvt-dev <intel-gvt-dev@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PULL] topic/gvt-ww-lock

Hey,

Op 22-09-2020 om 13:51 schreef Wang, Zhi A:
>
> Hi,
>
> Here's the patch which introduces GVT-g ww lock support against drm-intel-gt-next branch.
>
> Thanks
>
> --
>
> The following changes since commit 4316b19dee27cc5cd34a95fdbc0a3a5237507701:
>
>   drm/i915: Fix uninitialised variable in
> intel_context_create_request. (2020-09-21 11:09:46 +0200)
>
> are available in the git repository at:
>
>   https://github.com/intel/gvt-linux.git tags/gvt-ww-lock-09-22-2020
>
> for you to fetch changes up to e1b49ae155451aaa039eeb23fce808c71a038283:
>
>   drm/i915/gvt: Introduce per object locking in GVT scheduler.
> (2020-09-22 12:09:56 +0300)
>
> ----------------------------------------------------------------
> gvt-ww-lock-09-22-2020:
>
> - Introduce ww lock support into GVT-g.
>
> ----------------------------------------------------------------
> Zhi Wang (1):
>       drm/i915/gvt: Introduce per object locking in GVT scheduler.
>
>  drivers/gpu/drm/i915/gvt/scheduler.c | 68
> ++++++++++++++++++++++++++++++------
>  1 file changed, 57 insertions(+), 11 deletions(-)

I've taken a look at this branch, and I have some feedback.

Adding ww_ctx blindly like is done doesn't work. For example I'm working on a patch that adds ww handling to i915_gem_object_ggtt_pin(), so you don't have to perform manually in prepare_shadow_wa_ctx(). intel_context_pin() already has a ww dance, you can keep calling it without open coding it. If you do decide to call it manually, intel_context_put would have to be called after ctx_fini. Cheers, Maarten

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

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

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

      reply	other threads:[~2020-11-08  7:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22 11:51 [Intel-gfx] [PULL] topic/gvt-ww-lock Wang, Zhi A
2020-09-30 11:54 ` Maarten Lankhorst
2020-11-08  7:51   ` Wang, Zhi A [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=3ee7e0f7e16746619767b5ed913521b6@intel.com \
    --to=zhi.a.wang@intel.com \
    --cc=hang.yuan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=zhiyuan.lv@intel.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.