From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (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 A5B843F5BF1 for ; Wed, 5 Aug 2026 09:12:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.161 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785921168; cv=none; b=UE+l9wSMQlRjgFp4AoJkL8mEG21QTeGWxImX9mweUf4pJrf96NBHiHx7hG6wh207zDPbfIHbH/FCDpHOEwnAwUNSeXUZGXRQiJr8dbMc1SXhXs8K2q+cWbLpdqUAjlfdpDKzdgztIl7oJrYMBcqz9ZdeYviYec37zeUdWZM6QPM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785921168; c=relaxed/simple; bh=r3iZ+lFUZEsJBTzuychvBQ1Ca0+n8u+px9eNdOiqqvc=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=SA8Gf+Hl/ZVfqHp+MnJNd3hDKr4sC4uuglaL4Jx+hCgWlVAGKny+z/L9Ppp3N29GV7kEu+yzRNBiG6WIAe+6ZPwi0w2fl1geWk4ZTpFg39I7FxeyopyG5yjE/oUrJZV2rHDIY/Ce0AdPawV57BPcH4QtZZXSzcC9v6XoSCrwhZ4= 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; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=dMdf7S78; arc=none smtp.client-ip=80.241.56.161 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="dMdf7S78" Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (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-103.mailbox.org (Postfix) with ESMTPS id 4hFPnj2ZkvzKnXX; Wed, 05 Aug 2026 11:12:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1785921161; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r3iZ+lFUZEsJBTzuychvBQ1Ca0+n8u+px9eNdOiqqvc=; b=dMdf7S78nzJyAqIJlTMsT6eywbAjjrX+/L+SnQXsqEjyyRVHKvGvusRr70IwiOyZLxylAa Rmj4K0HXWOmKQYS/mckEbukJjHP1kCmlpcF19yRIBpRQ9FCsdtlxcfhx1PA28Nk6lqHR/i 00zmNRtxg2MMzTxrth7Ix7B1LCuNtYYZH7nZ2ehKUYeg5wyzJ3xImA3Z2sZTka2EKSu8gw BGsR5t8o0eE2BTj1prn3i1QgI8rJegHv7vWDqo8aXIT3hdsHe6L0eCFgXNYnhTPPKJiswi 7o2GlR4+1zYSj3pVfJGn98+eruzOEWlYJs3Pz5/jJnG6JISBnMZVJ2Gp7vCGJQ== Message-ID: <73de3de29ffbd36375a3a8d48f7ca840bf8f2d06.camel@mailbox.org> Subject: Re: [PATCH] drm/radeon: restore hardware polling in fence_is_signaled to fix performance regression From: Philipp Stanner Reply-To: phasta@kernel.org To: Christian =?ISO-8859-1?Q?K=F6nig?= , 2564278112@qq.com, alexander.deucher@amd.com Cc: airlied@gmail.com, simona@ffwll.ch, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Wang Jiang , Philipp Stanner , Danilo Krummrich Date: Wed, 05 Aug 2026 11:12:37 +0200 In-Reply-To: References: 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: 0b0204cefdf41debb11 X-MBO-RS-META: mddfdxogy45fcp43gf7167yu8yj59bn9 On Wed, 2026-08-05 at 10:34 +0200, Christian K=C3=B6nig wrote: > On 7/29/26 12:26, 2564278112@qq.com=C2=A0wrote: > > From: Wang Jiang > >=20 > > Commit 9eb00b5f5697b ("drm/radeon: delete radeon_fence_process in > > is_signaled, no deadlock") removed the hardware polling from > > radeon_fence_is_signaled() to fix a self-deadlock caused by > > wake_up_all(&rdev->fence_queue) being called with the fence queue > > lock held. > >=20 > > However, removing the polling entirely causes significant performance > > regression (e.g. glxgears FPS drop) because the fence signaled check > > becomes purely passive =E2=80=94 it only reads the cached last_seq with= out > > probing the GPU, so completed GPU work is not detected in time, > > causing unnecessary CPU stalls in sync-heavy workloads. > >=20 > > Fix this by calling radeon_fence_activity() directly instead of > > radeon_fence_process(). radeon_fence_activity() reads the hardware > > fence counter and updates last_seq via atomic ops without calling > > wake_up_all(), thus avoiding the deadlock while restoring timely > > fence detection. >=20 > Yeah I already feared that removing this in commit 9eb00b5f5697b > could cause issues. >=20 > Adding Philip and Danilo since we recently had a discussion about the > necessity of this. necessity of avoiding deadlocks with the callbacks somehow, or the necessity for opportunistic signaling? What we were wondering about was a) who can even reach the hardware_fence when the gpu scheduler's fence is in between and b) why it might be a problem if we lock in dma_fence_is_signaled(), because it would mean that someone (e.g. in userspace) is busy-looping on the fence. Since radeon does not use drm_sched, it seems to be one example for a), I can see that. Regards P.