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@xxxxxxxxx> > > > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
