From mboxrd@z Thu Jan 1 00:00:00 1970 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1EE6C433EF for ; Thu, 16 Jun 2022 07:33:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359449AbiFPHdx (ORCPT ); Thu, 16 Jun 2022 03:33:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359278AbiFPHdo (ORCPT ); Thu, 16 Jun 2022 03:33:44 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD1AB5F7A; Thu, 16 Jun 2022 00:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655364809; x=1686900809; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=5fosfAjzAZBHADth+UjPo9ukq2bY8/4uhcqIhxkcAbw=; b=Tz8KQnqtcitV72gD3CH2tNS7IN1ac6CtRKkjkj+ptxCg45E7XJednW8n mk+hidrXjgIKO8P+9AMDoYqXYLfq0blOaf9dLeay3HoC40G8k/BBmmF00 cyflPW5jhWMcHI2s8uQ5A75zOR84mqFiPRvtt5wNGOhYXQkVreI/gD7hM Uxp6YIrKQshfvap3XDIMM5iLFn2QDx/6MbHvjAMDnTv/FE+rHB0IPUPeN VSFIIzByoEULTZqQQhFunp+jOmw1DtFget2aV7oojGYR2MqsxspwGDsV0 y7rrai0iAmYMujacfrod1oau8CpuXo3eLYBlFQ2UOwJHVk1Fn/EgFnuJV A==; X-IronPort-AV: E=McAfee;i="6400,9594,10379"; a="267877773" X-IronPort-AV: E=Sophos;i="5.91,304,1647327600"; d="scan'208";a="267877773" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2022 00:33:29 -0700 X-IronPort-AV: E=Sophos;i="5.91,304,1647327600"; d="scan'208";a="912048023" Received: from mstokes1-mobl.ger.corp.intel.com (HELO [10.213.198.82]) ([10.213.198.82]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2022 00:33:25 -0700 Message-ID: <7c29c710-64ee-6e87-afb4-6d6b51e26315@linux.intel.com> Date: Thu, 16 Jun 2022 08:33:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 4/6] drm/i915/gt: Only invalidate TLBs exposed to user manipulation Content-Language: en-US To: Mauro Carvalho Chehab Cc: Chris Wilson , Fei Yang , Thomas Hellstrom , Daniel Vetter , Dave Airlie , David Airlie , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, mauro.chehab@linux.intel.com, Andi Shyti , stable@vger.kernel.org, =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= References: <387b9a8d3e719ad2db4fce56c0bfc0f909fd6df6.1655306128.git.mchehab@kernel.org> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: <387b9a8d3e719ad2db4fce56c0bfc0f909fd6df6.1655306128.git.mchehab@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On 15/06/2022 16:27, Mauro Carvalho Chehab wrote: > 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 of concurrent access > and stale access from prefetch. > > We only need to invalidate the TLB if they are accessible by the user. > > Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store") Same question as against the other patch - fix or optimisation? Regards, Tvrtko > Signed-off-by: Chris Wilson > Cc: Fei Yang > Cc: Andi Shyti > Cc: stable@vger.kernel.org > Acked-by: Thomas Hellström > Signed-off-by: Mauro Carvalho Chehab > --- > > See [PATCH 0/6] at: https://lore.kernel.org/all/cover.1655306128.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 0bffb70b3c5f..7989986161e8 100644 > --- a/drivers/gpu/drm/i915/i915_vma.c > +++ b/drivers/gpu/drm/i915/i915_vma.c > @@ -537,7 +537,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;