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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
