Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3505148imw; Mon, 18 Jul 2022 09:15:02 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vZuLq74RtgmmpGe2yw5ONz9Da6w+wg1cHJGZBqjC4ZwLAjI+jzqCI0WfFyN0YOa4ibIjww X-Received: by 2002:a05:620a:2807:b0:6a6:7055:48a0 with SMTP id f7-20020a05620a280700b006a6705548a0mr17866937qkp.8.1658160902123; Mon, 18 Jul 2022 09:15:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658160902; cv=none; d=google.com; s=arc-20160816; b=G1+DXOnuuKubmyT84jZDlOwPifKAreKiRTU9y2/kTv5fLh1/eO4i8tY6QsDxuO48FK 0NRicagpyku01kc8eDYt2GBbNs0WpSDICbAoOhrqos3ggYrCkUKPSkGl70GPFTSzIozp 8ql6G92/UB17uFx1ix4sUxwZq3PeW4v9NM/06SIF/0PrRp+hTFxMbrX9j7B8qIPaxEG7 Hfc7YBkzjV8PFepTLEqVfcAxu7cqModX2GVZgKXjZY6ulSp5LRS7HynyOOYY/ZtbnLm3 XCxZNJyrAFc4UZb2Wqka3bI0TwboW75WTVkaKVzwKuKrs4QHw9bdLUlNV2/190HyQ+su oSfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=JIxJplqTmZzlvrzeR0+lwqDIpqGVcUOThGcxgUs0qog=; b=iee5sUdBvvrL5rvaxi71efZ0Bg+4HGVPwPmkzRKjZD8/QlYgNKQStcmsmwjMgvg8SK O7eoQUpCN6uWwdZTOJzu1lygVdbuNEC/8/hu7Kv5/gU34Rdrhjo4xVaOPdCGz1TpavBO lO+Wwd/XTZPAZul/163h4CJB9fa9ngJpd0+dXrEJs2F/yYBGFap1YHo5LZj+UumLrhsV IDMXRW4Cw6H+A4G2swqiRD19cjOGsS9zBLTW5ceosno2OWzswQ/uAAOyCyK4wHWX3Rxv fNdgieYqSZCVMC2bmJ3bDEwSyT20xuYBVxHp2597tjflDr6KQaW9oQ0YVpoxR7drVlzF t8CQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="aKOP8/gk"; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dt4-20020a05620a478400b0069e5ce8c656si407756qkb.512.2022.07.18.09.14.32; Mon, 18 Jul 2022 09:15:02 -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="aKOP8/gk"; 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 S235551AbiGRQHE (ORCPT + 99 others); Mon, 18 Jul 2022 12:07:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235603AbiGRQHC (ORCPT ); Mon, 18 Jul 2022 12:07:02 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 687E92A710; Mon, 18 Jul 2022 09:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658160421; x=1689696421; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=BGMaJTElQp6haGmkH8rT8RsSQevkIPle8322hFlFuJg=; b=aKOP8/gklL+5oQX4jxLl9VSJCrY2ECVl9OT4mukzlfyt76kOv7TtGMqt 81Jt2hlaCS4O5KE8jF93/OY3T1edR8PxWJhLVy1OiLviglfQhXjreO9E1 k1cZNcM8bo0SufhVWZV+48FXc+B5gFbwvUDS48T2mh8Yy2CxJA/rSW0qD aubJcbZeueG0LEnVXyqsQ0GtCNxO8zIIq6hWVwImybzM9La06EMMuWdy1 5xMvxpu+ACpB/qN5UA9AZEMgu+4M9lwJyLij8rZh4J2gg4mb0WLfKULk6 jXVactYuoBSBvyqS4oAKBliShTuGV8CIVQN6IvHZouT7Cyfa8szr0Ja4L w==; X-IronPort-AV: E=McAfee;i="6400,9594,10412"; a="347947883" X-IronPort-AV: E=Sophos;i="5.92,281,1650956400"; d="scan'208";a="347947883" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2022 09:06:36 -0700 X-IronPort-AV: E=Sophos;i="5.92,281,1650956400"; d="scan'208";a="655347466" Received: from maurocar-mobl2.ger.corp.intel.com (HELO maurocar-mobl2) ([10.249.35.85]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2022 09:06:33 -0700 Date: Mon, 18 Jul 2022 18:06:30 +0200 From: Mauro Carvalho Chehab To: Tvrtko Ursulin Cc: Mauro Carvalho Chehab , Thomas =?UTF-8?B?SGVsbHN0?= =?UTF-8?B?csO2bQ==?= , David Airlie , dri-devel@lists.freedesktop.org, Lucas De Marchi , linux-kernel@vger.kernel.org, Chris Wilson , Rodrigo Vivi , Dave Airlie , stable@vger.kernel.org, intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v2 05/21] drm/i915/gt: Skip TLB invalidations once wedged Message-ID: <20220718180630.7bef2fd9@maurocar-mobl2> In-Reply-To: References: X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 Jul 2022 14:45:22 +0100 Tvrtko Ursulin wrote: > On 14/07/2022 13:06, Mauro Carvalho Chehab wrote: > > From: Chris Wilson > > > > Skip all further TLB invalidations once the device is wedged and > > had been reset, as, on such cases, it can no longer process instructions > > on the GPU and the user no longer has access to the TLB's in each engine. > > > > 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") > > Is the claim of a performance regression this solved based on a wedged > GPU which does not work any more to the extend where mmio tlb > invalidation requests keep timing out? If so please clarify in the > commit text and then it looks good to me. Even if it is IMO a very > borderline situation to declare something a fix. Indeed this helps on a borderline situation: if GT is wedged, TLB invalidation will timeout, so it makes sense to keep the patch with a comment like: drm/i915/gt: Skip TLB invalidations once wedged Skip all further TLB invalidations once the device is wedged and had been reset, as, on such cases, it can no longer process instructions on the GPU and the user no longer has access to the TLB's in each engine. So, an attempt to do a TLB cache invalidation will produce a timeout. That helps to reduce the performance regression introduced by TLB invalidate logic. Regards, Mauro