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
prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox