From patchwork Mon Nov 9 12:54:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 322743 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C95DDC388F7 for ; Mon, 9 Nov 2020 13:16:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7E18420867 for ; Mon, 9 Nov 2020 13:16:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604927763; bh=iOP7ju+nsPVXObKAVE6nR2KtqnYhNzet9YneRx9ANnU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=TNTc9dpNEgVYDuCeC3MnPRtM+amK3GOkJ2sc2Xwj1liQbmNNApqBYwhHU3fgu52aX rmrzkGhenP0tGQ1fcFo7NfmC8n4nDMrRyRR2zRFm95Ba7T37tAj99an8t5pFuSMxDZ Dm9jcsZB7hxyLI4EJjEQq2KsrQPG3eXsSnku5+uk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387419AbgKINQC (ORCPT ); Mon, 9 Nov 2020 08:16:02 -0500 Received: from mail.kernel.org ([198.145.29.99]:42890 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387413AbgKINQA (ORCPT ); Mon, 9 Nov 2020 08:16:00 -0500 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C49542083B; Mon, 9 Nov 2020 13:15:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604927759; bh=iOP7ju+nsPVXObKAVE6nR2KtqnYhNzet9YneRx9ANnU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PlkQjDn3/KlwbDfSM4x5kcYt5uv4Hr8ddLKvnHWeg/FoMRERjDK6UbmRHJGN4cjpG 4jkWFXJLmZfofHZit8hl7q3Ltec8aq8igERg4KLfkV+IH5EjSrGLX29XajleQkhtth 3OrEekDUKTQh6+PCuQuvnXlq4L3sq5M3o3qEz0GA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Chris Wilson , Mika Kuoppala , Bruce Chang , Ramalingam C , Joonas Lahtinen , Rodrigo Vivi Subject: [PATCH 5.9 012/133] drm/i915/gt: Undo forced context restores after trivial preemptions Date: Mon, 9 Nov 2020 13:54:34 +0100 Message-Id: <20201109125031.305457660@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201109125030.706496283@linuxfoundation.org> References: <20201109125030.706496283@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Chris Wilson commit 64402570e12f7b63ab33fc4640d3709c9ce2b380 upstream. We may try to preempt the currently executing request, only to find that after unravelling all the dependencies that the original executing context is still the earliest in the topological sort and re-submitted back to HW (if we do detect some change in the ELSP that requires re-submission). However, due to the way we check for wrap-around during the unravelling, we mark any context that has been submitted just once (i.e. with the rq->wa_tail set, but the ring->tail earlier) as potentially wrapping and requiring a forced restore on resubmission. This was expected to be not a problem, as it was anticipated that most unwinding for preemption would result in a context switch and the few that did not would be lost in the noise. It did not take long for someone to find one particular workload where the cost of those extra context restores was measurable. However, since we know the wa_tail is of fixed size, and we know that a request must be larger than the wa_tail itself, we can safely maintain the check for request wrapping and check against a slightly future point in the ring that includes an expected wa_tail. (That is if the ring->tail is already set to rq->wa_tail, including another 8 bytes in the check does not invalidate the incremental wrap detection.) Fixes: 8ab3a3812aa9 ("drm/i915/gt: Incrementally check for rewinding") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Bruce Chang Cc: Ramalingam C Cc: Joonas Lahtinen Cc: # v5.4+ Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20201002083425.4605-1-chris@chris-wilson.co.uk (cherry picked from commit bb65548e3c6e299175a9e8c3e24b2b9577656a5d) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/i915/gt/intel_lrc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -1139,9 +1139,8 @@ __unwind_incomplete_requests(struct inte /* Check in case we rollback so far we wrap [size/2] */ if (intel_ring_direction(rq->ring, - intel_ring_wrap(rq->ring, - rq->tail), - rq->ring->tail) > 0) + rq->tail, + rq->ring->tail + 8) > 0) rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE; active = rq;