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

Daniel Vetter daniel at ffwll.ch
Sat Oct 29 21:40:57 CEST 2011


On Sat, Oct 29, 2011 at 12:22:25PM -0700, Ben Widawsky wrote:
> On Sat, 29 Oct 2011 11:45:34 -0700
> Eric Anholt <eric at anholt.net> wrote:
> 
> > 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.
> > 
> > Just using wait_request interface would require less code and not have
> > that issue.
> 
> I must be missing something simple, but I didn't see an easy way to use
> that interface to do what I want. Instead of outstanding requests, I'd
> need to start tracking per fd seqnos (yes it's done elsewhere, but
> didn't seem much different to me).

We track request per-fd already in the file_priv, so if the oustanding
requests is already at the limit and would go over the top with an
additional request, you can just look at the previously submitted request
for this fd, grab it's seqno and wait for that. The ugly part then just
boils down to allowing wait_request without the struct_mutex held. But
that's rather generally usefull infrastructure.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48



More information about the Intel-gfx mailing list