Many sightings report the greater prevalence of allocation failures. This is all due to the incorrect use of mapping_gfp_constraint(), so remove it in favour of just querying the mapping_gfp_mask() which are the exact gfp_t we wanted in the first place.
We still do expect a higher chance of reporting ENOMEM, as that is the intention of using __GFP_NORETRY -- to fail rather than oom after having reclaimed from our bo caches, and having done a direct|kswapd reclaim pass. Reported-by: Jason Ekstrand <jason.ekstr...@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100594 Fixes: 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations") Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Cc: Daniel Vetter <daniel.vet...@ffwll.ch> --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 5f911a25e99a..57f51f1dac69 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2314,7 +2314,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj) * defer the oom here by reporting the ENOMEM back * to userspace. */ - reclaim = mapping_gfp_constraint(mapping, 0); + reclaim = mapping_gfp_mask(mapping); reclaim |= __GFP_NORETRY; /* reclaim, but no oom */ page = shmem_read_mapping_page_gfp(mapping, i, reclaim); -- 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
