> 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 ? 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. It doesn't address our underlying issue - userspace should still handle ENOSPC gracefully. However it certainly seems to be improving things considerably, so is beneficial if it really is a safe thing to do. Jon --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
