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@xxxxxxxxx>
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Akash Goel <akash.goel@xxxxxxxxx>
Cc: sourab.gupta@xxxxxxxxx
Cc: linux-mm@xxxxxxxxx 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
