Hi,
On 5 June 2017 at 11:35, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
