On to, 2017-06-01 at 14:33 +0100, Chris Wilson wrote:
> I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It
> struggles with handling reclaim via kswapd (through inconsistency within
> throttle_direct_reclaim() and even then the race between multiple
> allocators makes the two step of reclaim then allocate fragile), and as
> our buffers are always dirty (with very few exceptions), we required
> kswapd to perform pageout on them. The only effective means of waiting
> on kswapd is to retry the allocations (i.e. not set __GFP_NORETRY). That
> leaves us with the dilemma of invoking the oomkiller instead of
> propagating the allocation failure back to userspace where it can be
> handled more gracefully (one hopes). We cheat and note that __GFP_THISNODE
> has the side-effect of preventing oom and has no consequence for our final
> attempt at allocation.
>
> Fixes: 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
> Testcase: igt/gem_tiled_swapping
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
<SNIP>
> @@ -2406,7 +2406,21 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
> if (!*s) {
> /* reclaim and warn, but no oom */
> gfp = mapping_gfp_mask(mapping);
> - gfp |= __GFP_NORETRY;
> +
> + /* Our bo are always dirty and so we require
> + * kswapd to reclaim our pages (direct reclaim
> + * performs no swapping on its own). However,
> + * direct reclaim is meant to wait for kswapd
> + * when under pressure, this is broken. As a
> + * result __GFP_RECLAIM is unreliable and fails
> + * to actually reclaim dirty pages -- unless
> + * you try over and over again with
> + * !__GFP_NORETRY. However, we still want to
> + * fail this allocation rather than trigger
> + * the out-of-memory killer and for this we
> + * subvert __GFP_THISNODE for that side effect.
"side effect" sounds bad immediately, Daniel is on vacation so adding
Tvrtko and Mika here too.
Was this discussed with core MM?
Regards, Joonas
> + */
> + gfp |= __GFP_THISNODE;
> }
> } while (1);
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
