Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4166866imw; Tue, 19 Jul 2022 00:42:57 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vQCbjsRnIGi3Ruuxn3uKkfWuQVOR/XyRYkd7eot3oiKwlBzyGexE9YBOML12qtneO4kwRS X-Received: by 2002:a05:6a00:1daa:b0:52a:c51d:d36a with SMTP id z42-20020a056a001daa00b0052ac51dd36amr31808058pfw.61.1658216576941; Tue, 19 Jul 2022 00:42:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658216576; cv=none; d=google.com; s=arc-20160816; b=SyBKB8w0JuE90w5FIOlBqg1rmix37sNU+EsrWjng4BU7zS0rkJox59/Vhg7845WtOx xUFmLpE6hFJmAIVEgfFU4mramDGpv1Oo9GJCsfDT8VQAyDPYWxV+HFG5jnnYQ7HLQOR7 JNh6pBuJ9qKHWl8+2Jf7Mk30Qo/lgcNSFg7FVDka/NxIUTuwz2Z/XNDGpjjsBT88G3O/ jD0APHPsvxlEzvYbq+cSChi/XnHkXixFMsVqU4mAt43ia7CS/+xXe8qKRERc8CHZvRlM AEBpjGzh1NXhiBu4e2IV4kltAatJ5GIaNo8bwQF9QN3ezWBpdCw2/Z4pG4PARzCGJHEA qwuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:dkim-signature; bh=F/DbBoVCqATmjMxdKPWB1lb2LokZq8Y9HR2Jtht3UYg=; b=pS7udFpdmUzhtyxBHtZmHvDf7rMl0v1lqkFs555I+FJmTNLjOzcYJQ0qEM7NlD63pE vfHr007QwQBU2Wj3vEcz3Jlhxf46E4Q9v9wLYTnsrpnq8dYJLrUj+yX3tOUFSkabiXw7 uDrs80c3GXaJvbW8c0i4Ktc2H8lH/Jzj+cz0NzkOvCPAHri0SYQNvw98IyE0M2vArRWc mDaVqfDto4cQLH9pBy/X/3L5e8vUIoXA6AVdcgF9wwR1OQ51Ghh6MmPxB/BuW/cTK++5 fFajA9ivZKVoMnADJtkDRuyTqJ/X0pA8gy6Pk/CMfcjYlixqBqbJTfLnJP//v9q//jf+ w0AQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Vlj/tnv1"; 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 a62-20020a639041000000b00412b2911bf7si18505620pge.198.2022.07.19.00.42.42; Tue, 19 Jul 2022 00:42:56 -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="Vlj/tnv1"; 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 S235847AbiGSHUC (ORCPT + 99 others); Tue, 19 Jul 2022 03:20:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235928AbiGSHUA (ORCPT ); Tue, 19 Jul 2022 03:20:00 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6165E32EE0; Tue, 19 Jul 2022 00:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658215199; x=1689751199; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=efBx+cOjCDPM6QiEgXxI19AztXeKxc+R7d/gZgYJqAk=; b=Vlj/tnv1hnUEGAdbKJg8Nkj4aoW7KN+0JdMKboRIVymvI9p+UHnR8C/J 5syW5HxekSNy/Gn9SDLD2wXGz7hpoE2kbxNV7iXnkwES7qEpyWTGhNwrf RABVcmuAhz5gcVGhNOM7nrMYn2C6nxWgnYLLrFNTp89PENxNneWS/t89L KnA/3Wtoxmch/+39LBjMSD5SEbdssO7E+GSbbtlWiCopRWkQVV0xV5y+q qwPtvaE6QpP8qAwKRwPCCbvhJRnUkf2keI9knkrttn4DJYe9DHI8Zg4vC aHOQ7k8gI94TBp9o/5/FOxV0rtlu0PcIA73UK0FuiVi8IwKPXW5Guk83R w==; X-IronPort-AV: E=McAfee;i="6400,9594,10412"; a="266195978" X-IronPort-AV: E=Sophos;i="5.92,283,1650956400"; d="scan'208";a="266195978" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 00:19:58 -0700 X-IronPort-AV: E=Sophos;i="5.92,283,1650956400"; d="scan'208";a="601492485" Received: from ssherida-mobl.ger.corp.intel.com (HELO [10.213.201.170]) ([10.213.201.170]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 00:19:55 -0700 Message-ID: <4933d674-0b3e-0b79-7749-a796f7b1cb6f@linux.intel.com> Date: Tue, 19 Jul 2022 08:19:54 +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: [Intel-gfx] [PATCH v2 05/21] drm/i915/gt: Skip TLB invalidations once wedged Content-Language: en-US To: Mauro Carvalho Chehab Cc: Mauro Carvalho Chehab , =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= , 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 References: <20220718180630.7bef2fd9@maurocar-mobl2> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: <20220718180630.7bef2fd9@maurocar-mobl2> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HK_RANDOM_ENVFROM,HK_RANDOM_FROM, NICE_REPLY_A,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,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 18/07/2022 17:06, Mauro Carvalho Chehab wrote: > 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. Yeah that is better but whether bothering stable with it is the question. Wedged GPU means constant endless -EIO to userspace so very hard to imagine that after a TLB invalidation timeout or two there would be further ones. But okay, it's tiny so fine I guess. Regards, Tvrtko