Message ID | 20230330-hold_wakeref_for_active_vm-v2-1-724d201499c2@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp599375vqo; Fri, 31 Mar 2023 07:18:38 -0700 (PDT) X-Google-Smtp-Source: AKy350ZzKQVJzM8XJzG83unS8L8/3p3q2wfifFjMIMupPXUEsnDpFyE8WVYhmA+klsqpk0Si8eRi X-Received: by 2002:a17:906:7189:b0:930:6591:15ee with SMTP id h9-20020a170906718900b00930659115eemr29168582ejk.10.1680272318690; Fri, 31 Mar 2023 07:18:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680272318; cv=none; d=google.com; s=arc-20160816; b=QUk1MCZM5iRybmOUNUvOtQQcIyhNpRZwKb7k4NEn2GHrL1vFt3976bJdAGAsXiY4eU Vw/Bsg2UIbowsrI61uK2wE0v1NgFmbdlzWfWg2ATXZ1rSBdSvhqu7qpQsUOeDGR7gOTN DfkXHWWl9JUmLP1qmK1dM4kO6ijgmqdcdE6te1BjOFFJs5Ej/+1hcLjoMOV4HL3L/wDH j4YrGXoujlNI4YLJnOHBBoWaZtdVPS2hK2eP0ww3duoPj5Z3IuO+i6LnnS65cKqpZg99 JL3tEvbqa92N8uwjI/cqxSy1tGnjgxY4S417gtP0N7FfWCKAMxy9f0TM4a7ygf/+qbDd 9PuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=/7qOY14pQTVbnCM7+XOzIVeiYgVV/R9pPamthgw1T0Y=; b=o+MRCqSp5C5ttz3CyYdUptRXtwmZ/bQRCUU1G6ex3WTemg6DGjBsC91KqJXZ1SAhZ+ yUm9cNYB23z0LbF84lOle71UFEHgYDcBpzvUVBgufeYuX+Pm7QwEhbclSHRieJdX3Qx7 1zDq7DyFGRb/mT3lSAVvQ0uKSOpmrlVsy9zuYDDS2Wx9VSD4PI8PIlyPlnt2B2+/+NiQ NOQe7OkoCWsXrQDauKoRqjWuDybZiSeSHWXXvNK35Xp9LM2l4Kd2NPLjzIJIKBgaCFnE VeFbznzYgkyc19SM9IYPrE/0PuYx6IVHi8BhkLQ3MOyBLSfqbHTL32Pt5INuy7vTEp0s 06gA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=T1MUh1lA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id he32-20020a1709073da000b00927012f155fsi2951912ejc.285.2023.03.31.07.18.13; Fri, 31 Mar 2023 07:18:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=T1MUh1lA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232396AbjCaOQ4 (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Fri, 31 Mar 2023 10:16:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229850AbjCaOQy (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 31 Mar 2023 10:16:54 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21E6819A0 for <linux-kernel@vger.kernel.org>; Fri, 31 Mar 2023 07:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680272213; x=1711808213; h=from:date:subject:mime-version:content-transfer-encoding: message-id:to:cc; bh=+Gw96Y45VrA7zDyfXk2bjg7K7rgD+aCxxfZVw9eX3Uw=; b=T1MUh1lAGOW1vgWzdMFiAmYHjba75wonb7Olxl6uBdgsdCkW56Mlo5OC 6aAKBAVvJLDrmiSwxl+Q2ey+UkcNa1uvVT91Zt8mifgP1a2npyFcFJQ1j vSpBedIGv8YxrDKK/BQaBEQVJSmmIi5E9BDn0I1eHrjB2J37RIr+XoTb0 ycsvmsjwZtU9LFa9JfWVuZa8qHAxQQsSbuKEaqvXpBRQF7RqUyrdB2Eht yluKtFZS1c2RTlArgeIQ9tlMybUTZ02X3y7J+W0a/Eh+Y0wSrswTNeGPI BHF39sQy6oWjRFDA0wsNP08gLiErB+IDNMdz5Ha1qYJVXSRFcPePekOTe w==; X-IronPort-AV: E=McAfee;i="6600,9927,10666"; a="321113028" X-IronPort-AV: E=Sophos;i="5.98,307,1673942400"; d="scan'208";a="321113028" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2023 07:16:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10666"; a="717730409" X-IronPort-AV: E=Sophos;i="5.98,307,1673942400"; d="scan'208";a="717730409" Received: from lab-ah.igk.intel.com ([10.102.138.202]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2023 07:16:48 -0700 From: Andrzej Hajda <andrzej.hajda@intel.com> Date: Fri, 31 Mar 2023 16:16:36 +0200 Subject: [PATCH v2] drm/i915/gt: Hold a wakeref for the active VM MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230330-hold_wakeref_for_active_vm-v2-1-724d201499c2@intel.com> X-B4-Tracking: v=1; b=H4sIAETrJmQC/42OSw6DIBRFt2IYl4aP0dhR99EYgvgoL1UxQGgb4 96LrqDDc2/uZyMRAkIkt2ojATJG9EsBcamIcXp5AsWxMBFMSCYlo85Po3rrFwSwyvqgtEmYQeWZ tpZxqeu6AytJKRh0BDoEvRh3VIxhpgnXw1lLGD/n7KMv7DAmH77ni8wP9a/BzCmngza65aLphG3 uuCSYrsbPpN/3/QdPBHkC3gAAAA== To: Jani Nikula <jani.nikula@linux.intel.com>, Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Chris Wilson <chris.p.wilson@linux.intel.com>, Andi Shyti <andi.shyti@linux.intel.com>, Chris Wilson <chris@chris-wilson.co.uk>, Andrzej Hajda <andrzej.hajda@intel.com> X-Mailer: b4 0.11.1 X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761893226828590265?= X-GMAIL-MSGID: =?utf-8?q?1761893226828590265?= |
Series |
[v2] drm/i915/gt: Hold a wakeref for the active VM
|
|
Commit Message
Andrzej Hajda
March 31, 2023, 2:16 p.m. UTC
From: Chris Wilson <chris@chris-wilson.co.uk> There may be a disconnect between the GT used by the engine and the GT used for the VM, requiring us to hold a wakeref on both while the GPU is active with this request. v2: added explanation to __queue_and_release_pm Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [ahajda: removed not-yet-upstremed wakeref tracking bits] Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> --- Changes in v2: - Link to v1: https://lore.kernel.org/r/20230330-hold_wakeref_for_active_vm-v1-1-baca712692f6@intel.com --- drivers/gpu/drm/i915/gt/intel_context.h | 15 +++++++++++---- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 9 +++++++++ 2 files changed, 20 insertions(+), 4 deletions(-) --- base-commit: 3385d6482cd60f2a0bbb0fa97b70ae7dbba4f95c change-id: 20230330-hold_wakeref_for_active_vm-7f013a449ef3 Best regards,
Comments
On 31/03/2023 15:16, Andrzej Hajda wrote: > From: Chris Wilson <chris@chris-wilson.co.uk> > > There may be a disconnect between the GT used by the engine and the GT > used for the VM, requiring us to hold a wakeref on both while the GPU is > active with this request. > > v2: added explanation to __queue_and_release_pm > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > [ahajda: removed not-yet-upstremed wakeref tracking bits] > Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> > --- > Changes in v2: > - Link to v1: https://lore.kernel.org/r/20230330-hold_wakeref_for_active_vm-v1-1-baca712692f6@intel.com > --- > drivers/gpu/drm/i915/gt/intel_context.h | 15 +++++++++++---- > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 9 +++++++++ > 2 files changed, 20 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h > index 0a8d553da3f439..48f888c3da083b 100644 > --- a/drivers/gpu/drm/i915/gt/intel_context.h > +++ b/drivers/gpu/drm/i915/gt/intel_context.h > @@ -14,6 +14,7 @@ > #include "i915_drv.h" > #include "intel_context_types.h" > #include "intel_engine_types.h" > +#include "intel_gt_pm.h" > #include "intel_ring_types.h" > #include "intel_timeline_types.h" > #include "i915_trace.h" > @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce); > static inline void intel_context_enter(struct intel_context *ce) > { > lockdep_assert_held(&ce->timeline->mutex); > - if (!ce->active_count++) > - ce->ops->enter(ce); > + if (ce->active_count++) > + return; > + > + ce->ops->enter(ce); > + intel_gt_pm_get(ce->vm->gt); > } > > static inline void intel_context_mark_active(struct intel_context *ce) > @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context *ce) > { > lockdep_assert_held(&ce->timeline->mutex); > GEM_BUG_ON(!ce->active_count); > - if (!--ce->active_count) > - ce->ops->exit(ce); > + if (--ce->active_count) > + return; > + > + intel_gt_pm_put_async(ce->vm->gt); > + ce->ops->exit(ce); > } > > static inline struct intel_context *intel_context_get(struct intel_context *ce) > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > index e971b153fda976..ee531a5c142c77 100644 > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > @@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq, > > ENGINE_TRACE(engine, "parking\n"); > > + /* > + * Open coded one half of intel_context_enter, which we have to omit > + * here (see the large comment below) and because the other part must > + * not be called due constructing directly with __i915_request_create > + * which increments active count via intel_context_mark_active. > + */ > + GEM_BUG_ON(rq->context->active_count != 1); > + __intel_gt_pm_get(engine->gt); > + > /* > * We have to serialise all potential retirement paths with our > * submission, as we don't want to underflow either the Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Regards, Tvrtko
Hi Andrzej, > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h > index 0a8d553da3f439..48f888c3da083b 100644 > --- a/drivers/gpu/drm/i915/gt/intel_context.h > +++ b/drivers/gpu/drm/i915/gt/intel_context.h > @@ -14,6 +14,7 @@ > #include "i915_drv.h" > #include "intel_context_types.h" > #include "intel_engine_types.h" > +#include "intel_gt_pm.h" > #include "intel_ring_types.h" > #include "intel_timeline_types.h" > #include "i915_trace.h" > @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce); > static inline void intel_context_enter(struct intel_context *ce) > { > lockdep_assert_held(&ce->timeline->mutex); > - if (!ce->active_count++) > - ce->ops->enter(ce); > + if (ce->active_count++) > + return; > + > + ce->ops->enter(ce); > + intel_gt_pm_get(ce->vm->gt); > } > > static inline void intel_context_mark_active(struct intel_context *ce) > @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context *ce) > { > lockdep_assert_held(&ce->timeline->mutex); > GEM_BUG_ON(!ce->active_count); > - if (!--ce->active_count) > - ce->ops->exit(ce); > + if (--ce->active_count) > + return; > + > + intel_gt_pm_put_async(ce->vm->gt); > + ce->ops->exit(ce); shouldn't these two be swapped? > } > > static inline struct intel_context *intel_context_get(struct intel_context *ce) > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > index e971b153fda976..ee531a5c142c77 100644 > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > @@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq, > > ENGINE_TRACE(engine, "parking\n"); > > + /* > + * Open coded one half of intel_context_enter, which we have to omit > + * here (see the large comment below) and because the other part must > + * not be called due constructing directly with __i915_request_create > + * which increments active count via intel_context_mark_active. > + */ > + GEM_BUG_ON(rq->context->active_count != 1); > + __intel_gt_pm_get(engine->gt); where is it's brother "put"? Thanks, Andi > + > /* > * We have to serialise all potential retirement paths with our > * submission, as we don't want to underflow either the > > --- > base-commit: 3385d6482cd60f2a0bbb0fa97b70ae7dbba4f95c > change-id: 20230330-hold_wakeref_for_active_vm-7f013a449ef3 > > Best regards, > -- > Andrzej Hajda <andrzej.hajda@intel.com>
On 04/04/2023 16:39, Andi Shyti wrote: > Hi Andrzej, > >> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h >> index 0a8d553da3f439..48f888c3da083b 100644 >> --- a/drivers/gpu/drm/i915/gt/intel_context.h >> +++ b/drivers/gpu/drm/i915/gt/intel_context.h >> @@ -14,6 +14,7 @@ >> #include "i915_drv.h" >> #include "intel_context_types.h" >> #include "intel_engine_types.h" >> +#include "intel_gt_pm.h" >> #include "intel_ring_types.h" >> #include "intel_timeline_types.h" >> #include "i915_trace.h" >> @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce); >> static inline void intel_context_enter(struct intel_context *ce) >> { >> lockdep_assert_held(&ce->timeline->mutex); >> - if (!ce->active_count++) >> - ce->ops->enter(ce); >> + if (ce->active_count++) >> + return; >> + >> + ce->ops->enter(ce); >> + intel_gt_pm_get(ce->vm->gt); >> } >> >> static inline void intel_context_mark_active(struct intel_context *ce) >> @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context *ce) >> { >> lockdep_assert_held(&ce->timeline->mutex); >> GEM_BUG_ON(!ce->active_count); >> - if (!--ce->active_count) >> - ce->ops->exit(ce); >> + if (--ce->active_count) >> + return; >> + >> + intel_gt_pm_put_async(ce->vm->gt); >> + ce->ops->exit(ce); > > shouldn't these two be swapped? > >> } >> >> static inline struct intel_context *intel_context_get(struct intel_context *ce) >> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c >> index e971b153fda976..ee531a5c142c77 100644 >> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c >> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c >> @@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq, >> >> ENGINE_TRACE(engine, "parking\n"); >> >> + /* >> + * Open coded one half of intel_context_enter, which we have to omit >> + * here (see the large comment below) and because the other part must >> + * not be called due constructing directly with __i915_request_create >> + * which increments active count via intel_context_mark_active. >> + */ >> + GEM_BUG_ON(rq->context->active_count != 1); >> + __intel_gt_pm_get(engine->gt); > > where is it's brother "put"? It's in request retire via intel_context_exit. Ie. request construction is special here, while retirement is standard. Regards, Tvrtko > > Thanks, > Andi > >> + >> /* >> * We have to serialise all potential retirement paths with our >> * submission, as we don't want to underflow either the >> >> --- >> base-commit: 3385d6482cd60f2a0bbb0fa97b70ae7dbba4f95c >> change-id: 20230330-hold_wakeref_for_active_vm-7f013a449ef3 >> >> Best regards, >> -- >> Andrzej Hajda <andrzej.hajda@intel.com>
Hi Tvrtko, > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h > > > index 0a8d553da3f439..48f888c3da083b 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_context.h > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.h > > > @@ -14,6 +14,7 @@ > > > #include "i915_drv.h" > > > #include "intel_context_types.h" > > > #include "intel_engine_types.h" > > > +#include "intel_gt_pm.h" > > > #include "intel_ring_types.h" > > > #include "intel_timeline_types.h" > > > #include "i915_trace.h" > > > @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce); > > > static inline void intel_context_enter(struct intel_context *ce) > > > { > > > lockdep_assert_held(&ce->timeline->mutex); > > > - if (!ce->active_count++) > > > - ce->ops->enter(ce); > > > + if (ce->active_count++) > > > + return; > > > + > > > + ce->ops->enter(ce); > > > + intel_gt_pm_get(ce->vm->gt); > > > } > > > static inline void intel_context_mark_active(struct intel_context *ce) > > > @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context *ce) > > > { > > > lockdep_assert_held(&ce->timeline->mutex); > > > GEM_BUG_ON(!ce->active_count); > > > - if (!--ce->active_count) > > > - ce->ops->exit(ce); > > > + if (--ce->active_count) > > > + return; > > > + > > > + intel_gt_pm_put_async(ce->vm->gt); > > > + ce->ops->exit(ce); > > > > shouldn't these two be swapped? maybe I wasn't clear here... shouldn't it be ce->ops->exit(ce); intel_gt_pm_put_async(ce->vm->gt); Don't we need to hold the pm until exiting? > > > } > > > static inline struct intel_context *intel_context_get(struct intel_context *ce) > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > index e971b153fda976..ee531a5c142c77 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > @@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq, > > > ENGINE_TRACE(engine, "parking\n"); > > > + /* > > > + * Open coded one half of intel_context_enter, which we have to omit > > > + * here (see the large comment below) and because the other part must > > > + * not be called due constructing directly with __i915_request_create > > > + * which increments active count via intel_context_mark_active. > > > + */ > > > + GEM_BUG_ON(rq->context->active_count != 1); > > > + __intel_gt_pm_get(engine->gt); > > > > where is it's brother "put"? > > It's in request retire via intel_context_exit. Ie. request construction is > special here, while retirement is standard. Thank you! Andi
On 04/04/2023 17:00, Andi Shyti wrote: > Hi Tvrtko, > >>>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h >>>> index 0a8d553da3f439..48f888c3da083b 100644 >>>> --- a/drivers/gpu/drm/i915/gt/intel_context.h >>>> +++ b/drivers/gpu/drm/i915/gt/intel_context.h >>>> @@ -14,6 +14,7 @@ >>>> #include "i915_drv.h" >>>> #include "intel_context_types.h" >>>> #include "intel_engine_types.h" >>>> +#include "intel_gt_pm.h" >>>> #include "intel_ring_types.h" >>>> #include "intel_timeline_types.h" >>>> #include "i915_trace.h" >>>> @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce); >>>> static inline void intel_context_enter(struct intel_context *ce) >>>> { >>>> lockdep_assert_held(&ce->timeline->mutex); >>>> - if (!ce->active_count++) >>>> - ce->ops->enter(ce); >>>> + if (ce->active_count++) >>>> + return; >>>> + >>>> + ce->ops->enter(ce); >>>> + intel_gt_pm_get(ce->vm->gt); >>>> } >>>> static inline void intel_context_mark_active(struct intel_context *ce) >>>> @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context *ce) >>>> { >>>> lockdep_assert_held(&ce->timeline->mutex); >>>> GEM_BUG_ON(!ce->active_count); >>>> - if (!--ce->active_count) >>>> - ce->ops->exit(ce); >>>> + if (--ce->active_count) >>>> + return; >>>> + >>>> + intel_gt_pm_put_async(ce->vm->gt); >>>> + ce->ops->exit(ce); >>> >>> shouldn't these two be swapped? > > maybe I wasn't clear here... shouldn't it be I missed this one. > ce->ops->exit(ce); > intel_gt_pm_put_async(ce->vm->gt); > > Don't we need to hold the pm until exiting? I think it doesn't matter. The problematic edge case this is fixing is when ce->engine->gt is different from ce->vm->gt but at this point if it is safe to release one it must be safe to release the other too. Regards, Tvrtko > >>>> } >>>> static inline struct intel_context *intel_context_get(struct intel_context *ce) >>>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c >>>> index e971b153fda976..ee531a5c142c77 100644 >>>> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c >>>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c >>>> @@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq, >>>> ENGINE_TRACE(engine, "parking\n"); >>>> + /* >>>> + * Open coded one half of intel_context_enter, which we have to omit >>>> + * here (see the large comment below) and because the other part must >>>> + * not be called due constructing directly with __i915_request_create >>>> + * which increments active count via intel_context_mark_active. >>>> + */ >>>> + GEM_BUG_ON(rq->context->active_count != 1); >>>> + __intel_gt_pm_get(engine->gt); >>> >>> where is it's brother "put"? >> >> It's in request retire via intel_context_exit. Ie. request construction is >> special here, while retirement is standard. > > Thank you! > Andi
Hi, On Fri, Mar 31, 2023 at 04:16:36PM +0200, Andrzej Hajda wrote: > From: Chris Wilson <chris@chris-wilson.co.uk> > > There may be a disconnect between the GT used by the engine and the GT > used for the VM, requiring us to hold a wakeref on both while the GPU is > active with this request. > > v2: added explanation to __queue_and_release_pm > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > [ahajda: removed not-yet-upstremed wakeref tracking bits] > Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Thank you Tvrtko and Chris for answering my questions, Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Andi
On 31.03.2023 16:16, Andrzej Hajda wrote: > From: Chris Wilson <chris@chris-wilson.co.uk> > > There may be a disconnect between the GT used by the engine and the GT > used for the VM, requiring us to hold a wakeref on both while the GPU is > active with this request. > > v2: added explanation to __queue_and_release_pm > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > [ahajda: removed not-yet-upstremed wakeref tracking bits] > Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Queued. Regards Andrzej
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h index 0a8d553da3f439..48f888c3da083b 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.h +++ b/drivers/gpu/drm/i915/gt/intel_context.h @@ -14,6 +14,7 @@ #include "i915_drv.h" #include "intel_context_types.h" #include "intel_engine_types.h" +#include "intel_gt_pm.h" #include "intel_ring_types.h" #include "intel_timeline_types.h" #include "i915_trace.h" @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce); static inline void intel_context_enter(struct intel_context *ce) { lockdep_assert_held(&ce->timeline->mutex); - if (!ce->active_count++) - ce->ops->enter(ce); + if (ce->active_count++) + return; + + ce->ops->enter(ce); + intel_gt_pm_get(ce->vm->gt); } static inline void intel_context_mark_active(struct intel_context *ce) @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context *ce) { lockdep_assert_held(&ce->timeline->mutex); GEM_BUG_ON(!ce->active_count); - if (!--ce->active_count) - ce->ops->exit(ce); + if (--ce->active_count) + return; + + intel_gt_pm_put_async(ce->vm->gt); + ce->ops->exit(ce); } static inline struct intel_context *intel_context_get(struct intel_context *ce) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c index e971b153fda976..ee531a5c142c77 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c @@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq, ENGINE_TRACE(engine, "parking\n"); + /* + * Open coded one half of intel_context_enter, which we have to omit + * here (see the large comment below) and because the other part must + * not be called due constructing directly with __i915_request_create + * which increments active count via intel_context_mark_active. + */ + GEM_BUG_ON(rq->context->active_count != 1); + __intel_gt_pm_get(engine->gt); + /* * We have to serialise all potential retirement paths with our * submission, as we don't want to underflow either the