[Intel-gfx] [PATCH] drm/i915: Avoid GPU stalls from kswapd

Dave Gordon david.s.gordon at intel.com
Mon Jun 22 12:41:05 PDT 2015


On 22/06/15 16:35, Daniel Vetter wrote:
> On Mon, Jun 22, 2015 at 03:18:12PM +0100, Chris Wilson wrote:
>> On Mon, Jun 22, 2015 at 04:11:01PM +0200, Daniel Vetter wrote:
>>> On Fri, Jun 19, 2015 at 02:04:16PM +0100, Chris Wilson wrote:
>>>> Exclude active GPU pages from the purview of the background shrinker
>>>> (kswapd), as these cause uncontrollable GPU stalls. Given that the
>>>> shrinker is rerun until the freelists are satisfied, we should have
>>>> opportunity in subsequent passes to recover the pages once idle. If the
>>>> machine does run out of memory entirely, we have the forced idling in the
>>>> oom-notifier as a means of releasing all the pages we can before an oom
>>>> is prematurely executed.
>>>>
>>>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>>>> ---
>>>>  drivers/gpu/drm/i915/i915_drv.h          | 1 +
>>>>  drivers/gpu/drm/i915/i915_gem_shrinker.c | 8 ++++++--
>>>>  2 files changed, 7 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>>>> index 71f4ca5088e2..e0dcd018379f 100644
>>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>>> @@ -3185,6 +3185,7 @@ unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
>>>>  #define I915_SHRINK_PURGEABLE 0x1
>>>>  #define I915_SHRINK_UNBOUND 0x2
>>>>  #define I915_SHRINK_BOUND 0x4
>>>> +#define I915_SHRINK_ACTIVE 0x8
>>>>  unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv);
>>>>  void i915_gem_shrinker_init(struct drm_i915_private *dev_priv);
>>>>  
>>>> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c
>>>> index bd1cf921aead..8d25ec8a6559 100644
>>>> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
>>>> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
>>>> @@ -123,6 +123,10 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
>>>>  			    obj->madv != I915_MADV_DONTNEED)
>>>>  				continue;
>>>>  
>>>> +			if ((flags & I915_SHRINK_ACTIVE) == 0 &&
>>>
>>> Isn't there a "I'm kswapd" process flag we could use to make the shrinker
>>> a bit more clever between synchronous reclaim and kswap reclaim? Or has
>>> synchronous reclaim died as a thing?
>>
>> If we cared we can use the lock-stealer as a flag for when waiting may
>> be acceptable. But the better heuristic imo is to delay the stall until
>> all other sources of cache memory have been exhausted. Then either
>> kswapd or direct reclaim will flush the GPU in preference to killing
>> processes.
> 
> Well I'm more concerned about fairness since atm the shrinker stall gives
> us a very crude throttling of gpu processes. It makes sense not to stall
> kswapd though since that would just punish the system overall for no
> useful purpose at all. But punishing active processes would imo be a
> feature. Since we hold the BKL while shrinking that'll also automatically
> stall and gem users.
> -Daniel

GPU scheduler should give us some throttling and fairness :)

.Dave.



More information about the Intel-gfx mailing list