From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF720374163 for ; Thu, 5 Mar 2026 08:35:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772699738; cv=none; b=d/xo94pLLVqjd1Nq3lm+U6k4EiAMXCzmVX+7q3qVjqRI0BlTFyV9UfOZ+scmg4tfqxk653fzxA50uuBwy4E0xWAakOttB76+csbFZfNPMx+7WCMnyYGipFe4XdqPILdbm5XOneKfWXILi6A/6eREj88nkPgcsPlI81QgL7PthX4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772699738; c=relaxed/simple; bh=Wx5fr9nyGAXqEzNldUyyXtFCrXiVlYDrivs0aq8tGww=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=u+RBhD6Er2a71fvcltmnf1XMxcimeJyQK6PhZeXrghlFiiuuk7hYQwLoEU73Rh/PBWHGN7rtbSPBXesKdNmE5L+bhzPFRfGvoi+GTjnleZsk3frxzj+QrgHyv41k5JQ/jZu+BksFU7E6QgP8ca81ceyICnbkqCkFsZarJQNE7Ew= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ursulin.net; spf=pass smtp.mailfrom=ursulin.net; dkim=pass (2048-bit key) header.d=ursulin.net header.i=@ursulin.net header.b=WkdVVELU; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ursulin.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ursulin.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ursulin.net header.i=@ursulin.net header.b="WkdVVELU" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-48371119eacso92464595e9.2 for ; Thu, 05 Mar 2026 00:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ursulin.net; s=google; t=1772699735; x=1773304535; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=AJ7kziCJmU6DUEFzVrbnl92aleDcq4bLewZp19FKNx8=; b=WkdVVELUU9B1R8d1ZNIILCjTNUU7wLHj8PNPz7sEeTbB8Ajs/xUXyt7s5bkR6BJ5FU ncJKNq2QUADvN5Kx31+/eiqkitHUmHlIx/V1F9bP3LEmbn9tEGwP44DlBSdebla9vEJF CtACeouy2F6hQsmV9B+0aWkesFUtGGnF3JdZ0GQQN4WkI4Om062u7IHREDPvqAV0z/27 f2IL5hz3E2jv3eH/3NrV+gSEfaSk6XSf27sZtGymIv+M3PrCrb2hQF1V2ABnSx7g4aMw 2t4lw7KwyjC3qRGVm8LusBM0ebC1iHaprI4BtHgEeffunDoIM7jmnPSbiwJxS33nyN5W l9Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772699735; x=1773304535; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AJ7kziCJmU6DUEFzVrbnl92aleDcq4bLewZp19FKNx8=; b=ciKPNaM0HPmeOwCCSUYEZsDSMqHVJEvkdWERekwYNi1SHOdP7/C//VEgay/uZO539M 6W0m+CApVnoLJRAttD39lrK4rqDmAvAA8gY1cdNWTL7lQvu+FWv0eDFIPN/9GBl3riYG YmSCmPHXLCJIB/PzYT04x2ifnVZNbolRH27GbcS7KrcTbOy5oJnl0aA5KVXbSPn1GHs9 7GDgBo7Dj9obygJ9RLWfsdmB4YsoK6vfF7dXZy9BnFOSgzg4jiIOyiqK+04yunAKbILz ZhyKEnWP9vUjJnIefystWXQYtAdCvTvH4HS0iQm/7rTQ6AWsVVV9tOkAy7XCLV6eu0qt wJvQ== X-Forwarded-Encrypted: i=1; AJvYcCWxQVbsVJcMNqDwgWpU9+d/s4E3SSk5IPhMekCYh5yzRfvUfkBMJZUtqvL6GGsIMKXqDCg7Bk/+UcMmFjA=@vger.kernel.org X-Gm-Message-State: AOJu0YwdPsPWsDwKZjr655TOO3VCDxdMCI7MloMICgSMGpBvq6RcoqLH wb0e5kZb9aItf5NL8Ff5wfRX/0N9WZzYzNYIVicUhpH7l2x73DgVzgvbhK8qB4XDt2s= X-Gm-Gg: ATEYQzxjhc7AiStpty5wwYC+5a8SxS3En2a9X2x5vUFxmf1eKDP+kPvQ0KT3lPOn89L ryRGJygnJiyuPpzwDAH1DzBLhEJJN3pLAejpMBmK7V5oUaqWQ6V1eW7yB1f7WOhI5BkHrmTiwlz ixARzHH4Wtz/On3MkClrNmcPyQUjgO1/04wayr80pvRcLE592fQL21dRzz4Gd0fgNvVSF2/mkhK HJxflHGRN3ZAwdcziqx45Wr8Yfnp1uz5TWnEYmyqkWp87aOf9IXICW2rTVsEAZDXf5TjmdI7uH6 KsrzmObzIRXh8djveyijgry2ZvMKW9TFsjhZL0xOSLIdkOnAzELJ5QpkeyTAw6mLSawUSxFfMv1 qx2reO6TCkTjYQbMK5DVmb8qyeV8vnX5Ps42gGtuVpPmsfv8ztrnpNOibuk4xCl/4CONsrEJD1/ /pf5HmIXs7Qz6dx1u24FrSaajkW7sSQ7RZmA/5oVE/EN+A X-Received: by 2002:a05:600c:a07:b0:47f:b737:5ce0 with SMTP id 5b1f17b1804b1-4851988f31dmr81915425e9.23.1772699734857; Thu, 05 Mar 2026 00:35:34 -0800 (PST) Received: from [192.168.0.101] ([90.240.106.137]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4851fb27a20sm57635465e9.9.2026.03.05.00.35.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 00:35:34 -0800 (PST) Message-ID: Date: Thu, 5 Mar 2026 08:35:33 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: drm_sched run_job and scheduling latency To: Chia-I Wu , ML dri-devel , intel-xe@lists.freedesktop.org Cc: Boris Brezillon , Steven Price , Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Matthew Brost , Danilo Krummrich , Philipp Stanner , =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , Rodrigo Vivi , open list References: Content-Language: en-GB From: Tvrtko Ursulin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/03/2026 22:51, 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. > > I know drm_sched switched from kthread_worker to workqueue for better From a plain kthread actually. Anyway, I suggested trying the kthread_worker approach a few times in the past but never got round implementing it. Not dual paths but simply replacing the workqueues with kthread_workers. What is your thinking regarding how would the priority be configured? In terms of the default and mechanism to select a higher priority scheduling class. Regards, Tvrtko > scaling when xe was introduced. But if drm_sched can support either > workqueue or kthread_worker during drm_sched_init, drivers can > selectively use kthread_worker only for RT gpu queues. And because > drivers require CAP_SYS_NICE for RT gpu queues, this should not cause > scaling issues. > > Thoughts? Or perhaps this becomes less of an issue if all drm_sched > users have concrete plans for userspace submissions..