[Intel-gfx] [PATCH v2] drm/i915: Set our shrinker->batch to 4096 (~16MiB)

[Chris Wilson]

Quoting Chris Wilson (2017-08-16 15:23:06)
> Prefer to defer activating our GEM shrinker until we have a few
> megabytes to free; or we have accumulated sufficient mempressure by
> deferring the reclaim to force a shrink. The intent is that because our
> objects may typically be large, we are too effective at shrinking and
> are not rewarded for freeing more pages than the batch. It will also
> defer the initial shrinking to hopefully put it at a lower priority than
> say the buffer cache (although it will balance out over a number of
> reclaims, with GEM being more bursty).
> 
> v2: Give it a feedback system to try and tune the batch size towards
> an effective size for the available objects.
> v3: Start keeping track of shrinker stats in debugfs

I think this is helping a treat. Still we get shrinker stalls, but
(anecdotally sadly) they do not feel as bad. Hmm, I wonder if latencytop
helps, but I also need a consistent workload+environment to replay.

One task fills the buffercache (-> vmpressure, triggering
reclaim/kswapd), the other task does something simple like copying
between a ring of buffers slightly too large for memory? Hmm, can wrap
this is as a mode of gem_syslatency. Then we measure the latency of a
third party to wakeup events? Or something engineered to hit the vm?
-Chris