From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 0BA0E372B55 for ; Thu, 5 Mar 2026 10:19:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772705959; cv=none; b=BZz5nidBQBh1fKciykwzuWC26Fn899uwSbMHP33QGX8+qjIQQLetqXxb5Y8MtwoFhJWnK8dH5KuMnGdJny7WHIxd4V4R8TfRx33npipjSJtMtDufY424c+svRM0+MOBMqHA0Nn5/JI4yMYqSkq4KGVev3tvJ+ruBsH3Aoh7TwF0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772705959; c=relaxed/simple; bh=87X4PiGJ5ih9WdnSJcid1yjqnmVMdmlUK2MEPbibgvE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=AWl0B1UJqT1NWlIdhP5QBpXgFb9uZlR1gtX0l751nXwhgS0aaKW78quCZDpCOaDA2vkY6PPlQ5Rhkqw28fUKQLccZ6iT43K+rmxYOVJM4BUNZDHOCe+l1slcRRW/6cMy1gIcKmRd5qeepkM7i9XcPT/HqfhyIACTcUPb+BZeCbI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=VKUaFtXX; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="VKUaFtXX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1772705956; bh=87X4PiGJ5ih9WdnSJcid1yjqnmVMdmlUK2MEPbibgvE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VKUaFtXXVrrwlPGBVqqaGWRGji0CNlj8/X8hRPymCr+b2+rWAx19zS/2ady9Faetz +JgrgCM6Hfz7JGOPT5O6479t9V8gDCorQP88x+brcrCJMUrBsOBLNZX8DTcIKWr/jx lXwAmWAhfj6nXdaqWmGgTLAf42W5jb61VztIVXTvk3aCD43oaa1RBn1FKYDpmJlQGn 3L9mYt6EopMzBEooPlPmd+8Vx86qD/Pdlu7SKkT3h2UH4k7urEDDV9W12OsJAAKM0n YiohxIIjkjxjjLKzG4Y73g86PcVhe6/BzwZbCwaUx+niU8a3D1piuKbAxvz3h4ocUe 7zMWCvDGBw+ew== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id B3DB217E026C; Thu, 5 Mar 2026 11:19:15 +0100 (CET) Date: Thu, 5 Mar 2026 11:19:13 +0100 From: Boris Brezillon To: Matthew Brost Cc: , Chia-I Wu , ML dri-devel , , Steven Price , "Liviu Dudau" , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Danilo Krummrich , Christian =?UTF-8?B?S8O2bmln?= , Thomas =?UTF-8?B?SGVsbHN0csO2bQ==?= , Rodrigo Vivi , open list , Subject: Re: drm_sched run_job and scheduling latency Message-ID: <20260305111913.68fe93e7@fedora> In-Reply-To: References: <20260305092711.20069ca1@fedora> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 5 Mar 2026 01:10:06 -0800 Matthew Brost wrote: > I can't say I agree with either of you here. > > In about an hour, I seemingly have a bypass path working in DRM sched + > Xe, and my diff is: > > 108 insertions(+), 31 deletions(-) First of all, I'm not blindly rejecting the approach, see how I said "I'm not thrilled" not "No way!". So yeah, if you have something to propose, feel free to post the diff here or as an RFC on the ML. Secondly, I keep thinking the fast-path approach doesn't quite fix the problem at hand where we actually want queuing/dequeuing operations to match the priority of the HW/FW context, because if your HW context is high prio but you're struggling to fill the HW queue, it's not truly high prio. Note that it's problem that was made more evident with FW scheduling (and the 1:1 entity:sched association), before that we just had one thread that was dequeuing from entities and pushing to HW queues based on entities priorities, so priority was somehow better enforced. So yeah, even ignoring the discrepancy that might emerge from this new fast-path-run_job (and the potential maintenance burden we mentioned), saying "you'll get proper queueing/dequeuing priority enforcement only if you have no deps, and the pipeline is not full" is kinda limited IMHO. I'd rather we think about a solution that solves the entire problem, which both the kthread_work[er] and workqueue(RT) proposals do.