[Intel-gfx] [PATCH] drm/i915: Wait and retry if there is no space in the aperture mappable area

[Chris Wilson]

On Wed, Oct 23, 2013 at 09:44:09AM +0000, Bloomfield, Jon wrote:
> > On Tue, Oct 22, 2013 at 01:15:32PM +0100, Chris Wilson wrote:
> > > On Tue, Oct 22, 2013 at 12:04:17PM +0000, Siluvery, Arun wrote:
> > > > From: "Siluvery, Arun" <arun.siluvery at intel.com>
> > > >
> > > > When a mapping is requested and if there is no space the mapping
> > > > fails and the region is not physically backed. This results in
> > > > signal 7(SIGBUS), code 2 (BUS_ADRERR) when it is actually accessed.
> > > > This patch handles this error, continues to wait and retries to find space.
> > >
> > > Eh, no. The line before will remove everything from the aperture that
> > > is unpinned. Throwing an evict_everything in here breaks reservations,
> > > so I think you are just papering over a bug.
> > 
> > If we want to fix this for real (i.e. allow userspace to reliably map stuff,
> > mabye even bigger than the aperture) we need to fall back to suballocating
> > tile-row aligned strides of the buffer (maybe pick the tile row multiply in
> > between 1M-2M). Until that's done userspace can't rely on gtt mmaps relibly
> > working for large buffers. The current heuristics we're using is half of the
> > mappable space, but that's probably a bit too optimistic.
> > -Daniel
> 
> Is calling i915_gem_evict_everything() actually dangerous ? Despite its name, it appears to only evict unpinned buffers. Or am I missing something ?

It breaks the expectations of the callers, which when they have multiple
buffers to reserve at once have a better strategy than can be performed
individually on a buffer. (That is when evict-everything becomes
useful.)

> What it does do is update the status of buffers which are no longer in use on the ring by calling i915_gem_retire_requests(). So from what I can tell (from a 10 minute trawl of the code admittedly) all this patch is doing is getting a more up to date view of the GTT demands so that we only fail with ENOSPC if there are no pinned buffers which can now be unpinned.

No, evict-something also scans the requests to find the first available
slot large enough to fit the buffer. (Except when evict-something is
instructed not to block for pending retirement.)

There's a bug here if evict-everything finds something that
evict-something doesn't.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre