[Intel-gfx] [PATCH] drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations

[Chris Wilson]

On Wed, Mar 22, 2017 at 02:24:51PM +0100, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 03:11:58PM +0200, Joonas Lahtinen wrote:
> > On ke, 2017-03-22 at 11:05 +0000, Chris Wilson wrote:
> > > Since gfx allocations tend to be large, unmovable and disposable, report
> > > the allocation failure back to userspace as an ENOMEM rather than incur
> > > the oomkiller. We have already tried to make room by purging our own
> > > cached gfx objects, and the oomkiller doesn't attribute ownership of gfx
> > > objects so will likely pick the wrong candidate. Instead, let userspace
> > > see the ENOMEM.
> > > 
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > 
> > A-b from Daniel.
> > 
> > Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> 
> We suck. Oh well, Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>

Been mulling this over. It's not 100% (mostly deliberate in that I
didn't adjust the mapping's gfp and just this allocations), so some
oomkiller still creeps in, but it does greatly improve predictability of
failure. The only drawback is where a small client is unable to allocate
memory -- however, we already strived to recover enough memory from our
own pool, and gfx for the large part are recoverable, and userspace
should take ENOMEM in its stride. (Give or take the SIGBUS, but you get
those anyway on out of memory during GTT mmaps, and I only know of one
driver that took pains to handle that.) Still better than indescriminate
SIGKILL.

With that in mind, pushed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre