From patchwork Thu Jul 14 12:06:09 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 12917798 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DD9AEC433EF for ; Thu, 14 Jul 2022 12:07:18 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E95F31127A6; Thu, 14 Jul 2022 12:06:38 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 99376112953; Thu, 14 Jul 2022 12:06:33 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3FCAD61DE7; Thu, 14 Jul 2022 12:06:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E05F2C36AEB; Thu, 14 Jul 2022 12:06:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657800390; bh=Jh3Kqp3PsRoCdV/mDv7WITLyqYY/AxdJ08g/jrYtT8s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OIgjqA3dm1ZNcOs4sigMBewggrVchZpVTA5rNuae+XM7YrjOQHNW9/uymVQfTZDu9 Xxi0CncfiWX3qzNg0VM5v0h4yf6r/fp0ZbaKiHiocTVTEU4AKBTXHyDwKXA421eSs6 PFQ/48Ul/D/UNepuw+Yx03bwVqEsN0vHzE9ihZzdTRjMxUBvOsfx01M+SYgiB0sk6k pf/vJ6rMebk8cNf53NU2TFIU0VWQnPNWU6YojkyrNyDhGXnX4Xzep3yXrY3qPwcVvF ChOV3jdrTXnDovNmFCdrCyOLJ34wyvUwN6SaPSzogeSgmqYwa2zqftFBvbow6Ak34a SOyTtnfKEslWg== Received: from mchehab by mail.kernel.org with local (Exim 4.95) (envelope-from ) id 1oBxbv-0059se-RS; Thu, 14 Jul 2022 13:06:27 +0100 From: Mauro Carvalho Chehab To: Subject: [PATCH v2 04/21] drm/i915/gt: Only invalidate TLBs exposed to user manipulation Date: Thu, 14 Jul 2022 13:06:09 +0100 Message-Id: X-Mailer: git-send-email 2.36.1 In-Reply-To: References: MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tvrtko Ursulin , Fei Yang , =?utf-8?q?Thomas_Hellstr=C3=B6m?= , David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Chris Wilson , Rodrigo Vivi , Andi Shyti , Dave Airlie , stable@vger.kernel.org, Mauro Carvalho Chehab , intel-gfx@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" From: Chris Wilson Don't flush TLBs when the buffer is only used in the GGTT under full control of the kernel, as there's no risk of concurrent access and stale access from prefetch. We only need to invalidate the TLB if they are accessible by the user. That helps to reduce the performance regression introduced by TLB invalidate logic. Cc: stable@vger.kernel.org Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store") Signed-off-by: Chris Wilson Cc: Fei Yang Cc: Andi Shyti Acked-by: Thomas Hellström Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Andi Shyti --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v2 00/21] at: https://lore.kernel.org/all/cover.1657800199.git.mchehab@kernel.org/ drivers/gpu/drm/i915/i915_vma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index ef3b04c7e153..646f419b2035 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -538,7 +538,8 @@ int i915_vma_bind(struct i915_vma *vma, bind_flags); } - set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags); + if (bind_flags & I915_VMA_LOCAL_BIND) + set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags); atomic_or(bind_flags, &vma->flags); return 0;