[Intel-gfx] [PATCH] drm/i915: Evict everything if we detect we are buffer thrashing

Eric Anholt eric at anholt.net
Thu Dec 3 22:05:11 CET 2009


On Wed, 02 Dec 2009 09:41:06 +0000, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Tue, 01 Dec 2009 16:12:30 -0800, Ian Romanick <idr at freedesktop.org> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Chris Wilson wrote:
> > > By scanning the inactive list for a single buffer to evict instead of
> > > just popping the first elements until we have sufficient room may be
> > > give measurably higher throughput, but opens the possibility of
> > > thrashing between two large objects. If we spot that this happening,
> > > then simply clear the entire aperture and start afresh. The alternate
> > > is the page-fault-of-doom!
> > 
> > I'm a little bit dubious of this approach.  Has this been tested on any
> > applications that, for example, use a lot of large textures?  I'm
> > concerned that this will cause performance regressions on such apps.
> 
> Evicting everything is a bit callous, granted. The problem is that our
> aperture becomes fragmented and we do not clear the inactive and flushing
> list. If we only clear the inactive list then we are never guaranteed to
> clear enough contiguous aperture space to fit the two objects [the only way
> we can be sure that there is enough space in the entire aperture to map the
> two object simultaneously is because user-space makes that promise] and so
> we will still be subject to a relatively easy to trigger page-fault-of-doom
> scenario. [Just open a few large, but not huge, images in firefox.] So we
> need someway to trigger a flush when the CPU is copying data between two
> large objects mapped into the GTT but the inactive aperture space only
> contains enough room for one.
> 
> I agree that the critical part of this is only evicting everything iff we
> have to and this looked like the simplest heuristic to use.

I'm not sure I agree that the critical part is "only evicting everything
iff...".  If the last bind was for a fault, and we're trying to fault
something else in, don't evict the previously-faulted object (until there
are no objects remaining to evict).



More information about the Intel-gfx mailing list