Re: [PATCH] drm/i915: Encourage our shrinker more when our shmemfs allocations fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux