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

[Goel, Akash]

On 11/25/2015 3:28 PM, 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.

Though CONFIG_FRONTSWAP is not set yet, but recently ZRAM (Compressed 
Swap in RAM) has been enabled on some devices, so 'total_swap_pages' 
will be nonzero on those devices.

>>
>> 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?
>

Sorry the "only shrink inactive" patch has not been included yet.
Will pull these 2 patches.
5763ff0 drm/i915: Avoid GPU stalls from kswapd
c9c0f5e drm/i915: During shrink_all we only need to idle the GPU

Best regards
Akash

> 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
> 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
> -Chris
>