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@xxxxxxxxxxxxxxxxxx> > > > > A-b from Daniel. > > > > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > We suck. Oh well, Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
