From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5A3B941D12C for ; Wed, 12 Aug 2026 11:59:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786535948; cv=none; b=VvfwhVDPqvWIshFr3UJainlV3qZj79E4h4fyuQdI4J6OWpaPTwo3W3THtz1858J+rCkW/o4zdQVojn09n7hD7SRRXIzDuSZqsWSFXWpHS/7GgEf8YbQAgX4dnSRdld3+mMtHCqJdMQGu1yIl/kA78A1kbO6Y1N0AWb/S3d5TwXY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786535948; c=relaxed/simple; bh=ab/dspLni/b4dv8Ay9tnmQw141OhuiHs+HpEf0JrbD4=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=eQ/OUz1brsS7YXrHXm8LeFK7e4bSapN3iXyvraYpYiOPuCJjdL4SkhkF6MQKUf3xjBttQsvI+KSKZPs7VUI23/jTZvvRAdl3eJ8wL7cMmgHfpLpu9D3IoSZhvV8uAn+8He/jSJO7l4Tlzcy5FqtEwvBfNPlJxYiWAHDBA0ag9M0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; arc=none smtp.client-ip=80.241.56.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4hKn8L1qlzzKvxn; Wed, 12 Aug 2026 13:58:58 +0200 (CEST) Message-ID: <932892b196f7bbba7f5e9bff22f9b484854aaccc.camel@mailbox.org> Subject: Re: [REGRESSION] drm/sched: FAIR policy causes serious performance degradation at max GPU load on 9070XT From: Philipp Stanner Reply-To: phasta@kernel.org To: Tvrtko Ursulin , Luke.Wildhardt@proton.me Cc: Danilo Krummrich , phasta@kernel.org, "matthew.brost@intel.com" , "ckoenig.leichtzumerken@gmail.com" , "dri-devel@lists.freedesktop.org" , "regressions@lists.linux.dev" , "amd-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" Date: Wed, 12 Aug 2026 13:58:54 +0200 In-Reply-To: References: <6e2a207e-4db6-4d47-b1f6-9cb13b8d6eeb@igalia.com> <4OmZej9WiJ6-rsJ_lFcrmwtClAwMdN4oHXWH0p8FkIrhAn4LKS4O3q36wrdZrvjZHBNS8PZsvaIvR-1aFZfF2tDiy1cdMzTYNylcbGDQN68=@proton.me> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MBO-RS-ID: c458c48d41946d84b5f X-MBO-RS-META: 4gth8jcm81u5wkqkmj6m45i1ad48gjpj On Wed, 2026-08-12 at 12:37 +0100, Tvrtko Ursulin wrote: > Jokes aside, I agree with the above analysis that a better fix would be= =20 > to pull things under the lock, and interestingly, Philipp had a lock=20 > widening patch not so long ago but I don't remember what happened it or= =20 > how exactly did it look. It would possibly have fixed this problem. https://lore.kernel.org/dri-devel/a0d969408a5a55dfb6d0b3e65906fd7bbf3eee1c.= camel@mailbox.org/ TBH I got discouraged and increasingly dissatisfied with the state of our community, because whenever I try to fix things that are *obviously* broken and incorrect (and which were usually not broken by me), with relatively simple patches, I have to work uphill and only receive pushback. Reviewers and supporters are usually absent unless they want to have more features or performance-hacks added, though it is apparent that many indeed read what we are doing. Should things get better it's usually not acknowledged, and should things go wrong one runs danger of getting blamed with hindsight-bias. Had my patch landed and (speculatively) prevented this regression, no one would have noticed, but Phoronix would write some nice article about the FPS gain in video games, achieved by Tvrtko Ursulin :) Ah well. My vision for drm_sched has been that we absolutely need to start establishing strict computer science standards and have to prioritze formal correctness, simplicity and documentation over features and *especially* performance. Though I maybe should have tried to be more polite and diplomatic about it, the evidence that I see is that the DRM community does not actually want the above. At least I have to conclude that from the lack of encouraging participation and the presence of discouragement.=C2=A0 So if I want to add a spinlock for something obviously broken, the burden of proof is on me, not on the one who broke it. If I want to prevent someone from adding a 4th drm_sched_start_x() function for performance-reasons, then I receive not-so-nice emails. Folks here seem to want to continue like they did for the last 15 years. If anyone here reads this who *doesn't* want to continue like we did for the last 15 years, then I would kindly ask for public participation and help with moving things towards the right direction. Simple emails with "I support this idea, +1", would almost be enough. It would seem that these recent event might proof that I was right about our fundamental issues. P.