On la, 2017-05-20 at 10:33 +0100, Chris Wilson wrote:
> Commit 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than
> incur the oom for gfx allocations") made the bold decision to try and
> avoid the oomkiller by reporting -ENOMEM to userspace if our allocation
> failed after attempting to free enough buffer objects. In short, it
> appears we were giving up too easily (even before we start wondering if
> one pass of reclaim is as strong as we would like). Part of the problem
> is that if we only shrink just enough pages for our expected allocation,
> the likelihood of those pages becoming available to us is less than 100%
> To counter-act that we ask for twice the number of pages to be made
> available. Furthermore, we allow the shrinker to pull pages from the
> active list in later passes.
>
> Fixes: 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
2x factor seems like it might backfire in the future, I think I'd be
more comfortable with some fixed amount.
I'm also not sure if this logic should be outside of i915 module, needs
some A-b at least.
Code itself is,
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
