[Intel-gfx] [PATCH 0/3] RFC: force throttling/fairness

[Ben Widawsky]

On Sat, 29 Oct 2011 09:07:35 +0100
Chris Wilson <chris at chris-wilson.co.uk> wrote:

> On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky <ben at bwidawsk.net> wrote:
> > These patches are pretty raw as I'm hoping to get some comments before
> > working to hard too clean them up. The goal is GPU fairness for clients
> > running on i915.
> 
> The biggest danger I see is that num_outstanding is only decremented
> in retire_requests, which under the right circumstances (a single hog or
> a plurarity) will cause latencies of over 1s. Also this unnecessarily
> penalises benchmarks, i.e. a single active client.

Well single active clients only exist for 2d, right? I was thinking I'd
disable the scheduler, and only start using it when the user forced it,
or the number of open drm fds is > 1.

> 
> To start the bikeshedding, we need a debugfs to show the current clients
> and their scheduling data.

Agreed.

> 
> I would like to see the hog values moved at least into the file_priv and
> a gpuprio ioctl so that we can start prioritising by file. It would then
> be possible for a compositing render server to open a fd for it owns
> high priority composition and a fd per client and individual tune their
> priorities. And before you know what's hit you someone will request
> cgroups...

The interface for the internal customer more or less does this. Even more
complicated is that in the long run, we probably desire more than fd
granularity (webGL for instance). I was trying to keep this as general as
possible though as it does seem to solve a problem and can be built upon
easily.

> 
> It would probably be best to overengineer the ioctl interface as a
> facsimile of the more recent cpu schedulers.

Could you give some advice as to what parameters you would like to see?

> -Chris
> 

Ben