• Chris Wilson's avatar
    drm/i915: Remove __GFP_NORETRY from our buffer allocator · eaf41801
    Chris Wilson authored
    I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It
    struggles with handling reclaim of our dirty buffers and relies on
    reclaim via kswapd. As a result, a single pass of direct reclaim is
    unreliable when i915 occupies the majority of available memory, and the
    only means of effectively waiting on kswapd to amke progress is by not
    setting the __GFP_NORETRY flag and lopping. 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).  In the future we may have __GFP_MAYFAIL to allow repeats up until
    we genuinely run out of memory and the oomkiller would have been invoked.
    Until then, let the oomkiller wreck havoc.
    
    v2: Stop playing with side-effects of gfp flags and await __GFP_MAYFAIL
    v3: Update comments that direct reclaim only appears to be ignoring our
    dirty buffers!
    
    Fixes: 24f8e00a ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
    Testcase: igt/gem_tiled_swapping
    Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Michal Hocko <mhocko@suse.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20170609110350.1767-2-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
    eaf41801
i915_gem.c 142 KB