All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Stanner <phasta@mailbox.org>
To: "Michel Dänzer" <michel.daenzer@mailbox.org>,
	phasta@kernel.org, "Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: kernel-dev@igalia.com,
	"Christian König" <christian.koenig@amd.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Matthew Brost" <matthew.brost@intel.com>
Subject: Re: [RFC v3 06/14] drm/sched: Implement RR via FIFO
Date: Wed, 02 Apr 2025 14:00:43 +0200	[thread overview]
Message-ID: <58b680faeeeea1c317b43a34c71d978efe72009d.camel@mailbox.org> (raw)
In-Reply-To: <264be6a0-b9be-4430-9de4-276456e34214@mailbox.org>

On Wed, 2025-04-02 at 12:58 +0200, Michel Dänzer wrote:
> On 2025-04-02 12:46, Philipp Stanner wrote:
> > On Mon, 2025-03-31 at 21:16 +0100, Tvrtko Ursulin wrote:
> > > Round-robin being the non-default policy and unclear how much it
> > > is
> > > used,
> > > we can notice that it can be implemented using the FIFO data
> > > structures if
> > > we only invent a fake submit timestamp which is monotonically
> > > increasing
> > > inside drm_sched_rq instances.
> > > 
> > > So instead of remembering which was the last entity the scheduler
> > > worker
> > > picked, we can bump the picked one to the bottom of the tree,
> > > achieving
> > > the same round-robin behaviour.
> > > 
> > > Advantage is that we can consolidate to a single code path and
> > > remove
> > > a
> > > bunch of code. Downside is round-robin mode now needs to lock on
> > > the
> > > job
> > > pop path but that should not be visible.
> > 
> > Why did you decide to do it that way and then later remove RR &
> > FIFO
> > alltogether in patch 10, basically?
> > 
> > I think the far cleaner way for our development-process would be a
> > separate patch(-series) that *removes* RR completely. Advantages
> > are:
> > 
> >    1. It should be relatively easy to do
> >    2. It would simplify the existing code base independently of
> > what
> >       happens with your RFC series here
> >    3. Before changing everyone's scheduling policy to a completely
> > new,
> >       deadline-based one, we could first be sure for a few release
> >       cycles that everyone is now on FIFO, establishing common
> > ground.
> >    4. We could CC every- and anyone who might use RR or might know
> >       someone who does
> >    5. If it turns out we screwed up and someone really relies on
> > RR, it
> >       would be easy to revert.
> > 
> > I am not aware of any RR users and have, in past discussions, never
> > heard of any. So removing it is more tempting for the above
> > reasons.
> 
> https://gitlab.freedesktop.org/drm/amd/-/issues/2516 has a bunch of
> RR users...

Right, there's a number of people complaining about the regression. But
what I'm interested in is: how did it evolve since then. Are there
distributions who set the module parameter? Does Steam do it? Or is it
individual users who work around the problem that way?

https://gitlab.freedesktop.org/drm/amd/-/issues/2516#note_2679509

^ this comment for example seems to indicate that on newer Wayland
versions part of the problem has vanished?

  reply	other threads:[~2025-04-03  8:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31 20:16 [RFC v3 00/14] Deadline DRM scheduler Tvrtko Ursulin
2025-03-31 20:16 ` [RFC v3 01/14] drm/sched: Add some scheduling quality unit tests Tvrtko Ursulin
2025-03-31 20:16 ` [RFC v3 02/14] drm/sched: Avoid double re-lock on the job free path Tvrtko Ursulin
2025-03-31 20:16 ` [RFC v3 03/14] drm/sched: Consolidate drm_sched_job_timedout Tvrtko Ursulin
2025-03-31 20:16 ` [RFC v3 04/14] drm/sched: Clarify locked section in drm_sched_rq_select_entity_fifo Tvrtko Ursulin
2025-04-01 14:59   ` Tvrtko Ursulin
2025-03-31 20:16 ` [RFC v3 05/14] drm/sched: Consolidate drm_sched_rq_select_entity_rr Tvrtko Ursulin
2025-03-31 20:16 ` [RFC v3 06/14] drm/sched: Implement RR via FIFO Tvrtko Ursulin
2025-04-02 10:46   ` Philipp Stanner
2025-04-02 10:58     ` Michel Dänzer
2025-04-02 12:00       ` Philipp Stanner [this message]
2025-04-02 13:22         ` Michel Dänzer
2025-04-02 13:37           ` Christian König
2025-04-04  9:27             ` Tvrtko Ursulin
2025-04-02 12:25     ` Tvrtko Ursulin
2025-03-31 20:16 ` [RFC v3 07/14] drm/sched: Consolidate entity run queue management Tvrtko Ursulin
2025-03-31 20:16 ` [RFC v3 08/14] drm/sched: Move run queue related code into a separate file Tvrtko Ursulin
2025-03-31 20:17 ` [RFC v3 09/14] drm/sched: Add deadline policy Tvrtko Ursulin
2025-03-31 20:17 ` [RFC v3 10/14] drm/sched: Remove FIFO and RR and simplify to a single run queue Tvrtko Ursulin
2025-03-31 20:17 ` [RFC v3 11/14] drm/sched: Queue all free credits in one worker invocation Tvrtko Ursulin
2025-03-31 20:17 ` [RFC v3 12/14] drm/sched: Embed run queue singleton into the scheduler Tvrtko Ursulin
2025-03-31 20:17 ` [RFC v3 13/14] drm/sched: De-clutter drm_sched_init Tvrtko Ursulin
2025-03-31 20:17 ` [RFC v3 14/14] drm/sched: Scale deadlines depending on queue depth Tvrtko Ursulin
2025-04-02  6:49 ` [RFC v3 00/14] Deadline DRM scheduler Christian König
2025-04-02  8:26   ` Tvrtko Ursulin
2025-04-02 11:53     ` Christian König
2025-04-04  9:21       ` Tvrtko Ursulin
2025-04-02 10:37 ` Philipp Stanner
2025-04-02 12:17   ` Tvrtko Ursulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58b680faeeeea1c317b43a34c71d978efe72009d.camel@mailbox.org \
    --to=phasta@mailbox.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel-dev@igalia.com \
    --cc=matthew.brost@intel.com \
    --cc=michel.daenzer@mailbox.org \
    --cc=phasta@kernel.org \
    --cc=tvrtko.ursulin@igalia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.