From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-164.sinamail.sina.com.cn (mail3-164.sinamail.sina.com.cn [202.108.3.164]) (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 6087334EF06 for ; Fri, 6 Mar 2026 11:59:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.108.3.164 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772798350; cv=none; b=RgJXFCljwFNSsLaatVfFfGazHZzhQvO621HNOmdAq8IOUUt1kcqaSGxx5qrHQhrke7uZpde4mwyHruD2d3X9YlOS233Pfr4378bPtd1+sZ8Z30BFIJ+F8SzwvIiqrd0QIyVfuNEg/+dpdIfIJ74b3jx7x5F5xQceI+8QdHfF2XE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772798350; c=relaxed/simple; bh=LBsYk3yUZbxFNr2VtxaVb70u7fNutM0ZIRJFQgxwRrs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KUQYUeE3oIfhx6PRLeOz+bNR33nErNNZAqe3crkEkSYRIZ/0TJRf5YDBeWZQLKUAJDxAfnbadDYtEf4Qs1mPIGnI43EUNHtq/8E7Sjd1hiR4cpei3/3veZplkTruS7N0549iVVFg8YZzG3YqOMbMgPP2MQnsfNaakQcNaAxzdms= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b=y/ZuJpuW; arc=none smtp.client-ip=202.108.3.164 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b="y/ZuJpuW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1772798346; bh=avyToukqBCgR47QJWZapPZk3My1EVsZ0bDwSZ+GeHwg=; h=From:Subject:Date:Message-ID; b=y/ZuJpuW/spuye57O9uIOOaMK6WE+AlKHcC+36FCD48NvjQhcOsVwUo+O2oaD/niW gWif3V63VCLRzuAlM3HUqYE25obIAiEv6RYMEsQrMj0H2ZK4qdkYVrNTfiMzvIJnGw MJZmqw6n9gqB/ue4Ab8Upyn72KIjKFd1dqBJ8hAo= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.62.144]) by sina.com (10.54.253.32) with ESMTP id 69AAC15D00007DF9; Fri, 6 Mar 2026 19:58:22 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 7320354456676 X-SMAIL-UIID: C324B5B58FA84231A77A84B622E6BD47-20260306-195822-1 From: Hillf Danton To: Chia-I Wu Cc: Matthew Brost , DRI , intel-xe@lists.freedesktop.org, Danilo Krummrich , Philipp Stanner , Boris Brezillon , LKML Subject: Re: drm_sched run_job and scheduling latency Date: Fri, 6 Mar 2026 19:58:09 +0800 Message-ID: <20260306115811.695-1-hdanton@sina.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Thu, 5 Mar 2026 21:46:21 -0800 Chia-I Wu wrote: >On Thu, Mar 5, 2026 at 3:10 PM Hillf Danton wrote: >> On Wed, Mar 04, 2026 at 02:51:39PM -0800, Chia-I Wu wrote: >> > Hi, >> > >> > Our system compositor (surfaceflinger on android) submits gpu jobs >> > from a SCHED_FIFO thread to an RT gpu queue. However, because >> > workqueue threads are SCHED_NORMAL, the scheduling latency from submit >> > to run_job can sometimes cause frame misses. We are seeing this on >> > panthor and xe, but the issue should be common to all drm_sched users. >> > >> > Using a WQ_HIGHPRI workqueue helps, but it is still not RT (and won't >> > meet future android requirements). It seems either workqueue needs to >> > gain RT support, or drm_sched needs to support kthread_worker. >> > >> As RT means (in general) to some extent that the game of eevdf is played in >> __userspace__, but you are not PeterZ, so any issue like frame miss is >> understandably expected. >> Who made the workqueue worker a victim if the CPU cycles are not tight? >> Who is the new victim of a RT kthread worker? >> As RT is not free, what did you pay for it, given fewer RT success on market? >> > That is a deliberate decision for android, that avoiding frame misses > is a top priority. > > Also, I think most drm drivers already signal their fences from irq > handlers or rt threads for a similar reason. And the reasoning applies > to submissions as well. > If RT submission alone works for you then your CPU cycles are tight. And if your workloads are sanely correct then making workqueue and/or kthread worker RT barely makes sense because the right option is to buy CPU with higher capacity.