[Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects

[Daniel Vetter]

On Wed, Nov 25, 2015 at 09:58:28AM +0000, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 10:17:49AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 24, 2015 at 11:17:38PM +0000, Chris Wilson wrote:
> > > On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
> > > > On Mon, Nov 23, 2015 at 09:20:24AM +0000, Chris Wilson wrote:
> > > > > If the system has no available swap pages, we cannot make forward
> > > > > progress in the shrinker by releasing active pages, only by releasing
> > > > > purgeable pages which are immediately reaped. Take total_swap_pages into
> > > > > account when counting up available objects to be shrunk and subsequently
> > > > > shrinking them. By doing so, we avoid unbinding objects that cannot be
> > > > > shrunk and so wasting CPU cycles flushing those objects from the GPU to
> > > > > the system and then immediately back again (as they will more than
> > > > > likely be reused shortly after).
> > > > > 
> > > > > Based on a patch by Akash Goel.
> > > > > 
> > > > > Reported-by: Akash Goel <akash.goel at intel.com>
> > > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > > Cc: Akash Goel <akash.goel at intel.com>
> > > > > Cc: sourab.gupta at intel.com
> > > > 
> > > > Cc: linux-mm at kvack.org should be done on this one, just in case they have
> > > > ideas for proper interfaces for this. Which might be, given that Jerome
> > > > Glisse is working on swaput-to-vram and other fun stuff like that.
> > > > 
> > > > Also, how does stuff like zswap (or whatever "compress my swap in memory"
> > > > is called again) factor in here? Iirc Android very much does use that.
> > > 
> > > It doesn't. We would need
> > > 
> > > #include <linux/frontswap.h>
> > > 
> > > static bool swap_available(void)
> > > {
> > > 	return total_swap_pages || frontswap_enabled;
> > > }
> > > 
> > > But if that then returns true for Android it seems the primary usecase
> > > is invalidated.
> > 
> > Well swapping to frontswap should be ok. Trashing not so much, and if we
> > do that I suspect there's something really loopsided with memory usage
> > balancing going on ... Does the android workload have your "only shrink
> > inactive" patch already?
> 
> I'll let Akash or Sourab comment, but the background to the patch was
> that they observed that under memory pressure a framebuffer was being
> unbound (obviously not pinned as a current scanout) and then rebound
> (clflushing both ways ofc). My gut says that the priority lists in the
> kernel and userspace are akilter if we either fail to purge the LRU
> object in the kernel or if userspace then doesn't try to reuse the MRU
> backbuffer. One thing I did notice when also dealing with memory
> pressure flushing backbuffers was (a) they were unaligned and so needed
> rebinding before pinning
> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=df636036d120c6227d1918cfd6d70232d8d37b4c

Not sure I read this correctly, but shouldn't we cache the alignment for
as long as the buffer isn't purged? Your patch resets when we unpin the
last display user. So in your scenario above that could result in an
unaligned rebinding for GT first, then aligned rebinding for display. I
figured the idea is to get things right for the render right away?

Only risk is that we might overalign things, but that only happens when
userspace reuses fbs and non-fbs in a mixed fashion. But that shouldn't be
a real problem I think.

> and (b) we didn't bump the scanout on the inactive list
> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=3a23ff3e5e201a52068d6e9d65f4ffb95077c21e

Yeah bumping the inactive list when we unpin from display definitely makes
sense. Of course it only plays well together with the userspace fb cache
if that is indeed MRU, and I think Android's isn't. It's all strictly fifo
buffer queues, both between kernel and surface flinger and between surface
flinger and clients.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch