Re: [RFC 00/14] Deadline scheduler and other ideas

[Danilo Krummrich <dakr@redhat.com>]

On Wed, Jan 08, 2025 at 03:13:39PM +0000, Tvrtko Ursulin wrote:
> 
> On 08/01/2025 08:31, Danilo Krummrich wrote:
> > On Mon, Dec 30, 2024 at 04:52:45PM +0000, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> > 
> > "Deadline scheduler and other ideas"
> > 
> > There's a few patches that could be sent outside the scope of this series, e.g.
> > the first one.
> > 
> > I think it would make sense to do so.
> 
> For now I'll keep them at the head of this RFC and as they get acked or
> r-b-ed I can easily send them standalone or re-ordered. Until then having
> the series separate would make the RFC not standalone.
> 
> > > <tldr>
> > > Replacing FIFO with a flavour of deadline driven scheduling and removing round-
> > > robin. Connecting the scheduler with dma-fence deadlines. First draft and
> > > testing by different drivers and feedback would be nice. I was only able to test
> > > it with amdgpu. Other drivers may not even compile.
> > 
> > What are the results from your tests with amdgpu? Do you have some measurements?
> 
> We already covered this in the thread with Philipp to a degree. Tl;dr; the
> main idea is whether we simplify the code and at least not regress.
> 
> I don't expect improvements on the amdgpu side with the workloads like games
> and benchmarks. I did not measure anything significant apart that priorities
> seem to work with the run queues removed.

I appreaciate the effort, and generally I like the idea, but I also must admit
that this isn't the most convincing motiviation for such an integral change
(especially the "at least not regress" part).

I'd still like to encourage you to send the small cleanups separately, get them
in soon and leave the deadline scheduler as a separate RFC.

Meanwhile, Philipp is working on getting documentation straight and digging into
all the FIXMEs of the scheduler getting to a cleaner baseline. And with your
cleanups you're already helping with that.

For now, I'd prefer to leave the deadline scheduler stuff for when things are a
bit more settled and / or drivers declare the need.

> 
> Where something could show is if someone is aware of a workload where normal
> prio starves low. Since one part of the idea is that with the "deadline"
> scheme those should work a little bit more balanced.
> 
> Also again, feedback (including testing feedback from other drivers) would
> be great, and ideas of which workloads to test.

Unfortunately, there's not much I can tell from the Nouveau side of things,
since we're using the firmware scheduler scheme (one entity per scheduler) and
hence the scheduling strategy isn't that relevant.

> 
> Btw I will send a respin in a day or so which will clean up some things and
> adds some more tiny bits.
> 
> Regards,
> 
> Tvrtko