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

[Daniel Vetter]

On Sat, Oct 29, 2011 at 09:40:57PM +0200, Daniel Vetter wrote:
> 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.

Meh, not wait on the previously submitted req, but the first one to retire
next, obviously.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48