[Intel-gfx] [PATCH v2] drm/i915: Remove __GFP_NORETRY from our buffer allocator

[Daniel Stone]

Hi,

On 5 June 2017 at 11:35, Chris Wilson <chris at chris-wilson.co.uk> 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).

The i965 GL(ES) driver may dash your hopes somewhat:

         ret = execbuffer(dri_screen->fd, batch, hw_ctx,
                          4 * USED_BATCH(*batch),
                          in_fence_fd, out_fence_fd, flags);

   if (ret != 0) {
      fprintf(stderr, "intel_do_flush_locked failed: %s\n", strerror(-ret));
      exit(1);
   }

Before removing NORETRY, occasionally I'd get lucky and Chrome would
fail, but usually it'd be Mutter and my entire session would
disappear. I'm also not sure what a good strategy as a compositor
would be: just keep on trying updates until you get lucky? Sit doing
nothing for a while and hope redraws succeed 'later' ... ? Similarly
to Linus, I was in a position where reclaim should've been extremely
effective - into the gigabytes - at the time, so pushing reclaim
harder and taking a small time penalty seems far better than a hard
failure.

Cheers,
Daniel