[Intel-gfx] [PATCH v2 5/5] drm/i915: Start writeback from the shrinker

[Michal Hocko]

On Fri 09-06-17 12:51:57, Chris Wilson wrote:
> Quoting Michal Hocko (2017-06-09 12:17:26)
> > [Add Hugh]
> > 
> > On Fri 09-06-17 12:03:50, Chris Wilson wrote:
> > > When we are called to relieve mempressue via the shrinker, the only way
> > > we can make progress is either by discarding unwanted pages (those
> > > objects that userspace has marked MADV_DONTNEED) or by reclaiming the
> > > dirty objects via swap. As we know that is the only way to make further
> > > progress, we can initiate the writeback as we invalidate the objects.
> > > This means the objects we put onto the inactive anon lru list are
> > > already marked for reclaim+writeback and so will trigger a wait upon the
> > > writeback inside direct reclaim, greatly improving the success rate of
> > > direct reclaim on i915 objects.
> > > 
> > > The corollary is that we may start a slow swap on opportunistic
> > > mempressure from the likes of the compaction + migration kthreads. This
> > > is limited by those threads only being allowed to shrink idle pages, but
> > > also that if we reactivate the page before it is swapped out by gpu
> > > activity, we only page the cost of repinning the page. The cost is most
> > > felt when an object is reused after mempressure, which hopefully
> > > excludes the latency sensitive tasks (as we are just extending the
> > > impact of swap thrashing to them).
> > 
> > I am not sure you can start writeback on shmem while it is not in the
> > swapcache. Hugh?
> 
> Note this is just mm/vmscan.c::pageout(), and we call into shmem which
> is indeed responsible for adding it to the swapcache.

You are right. I would still like to hear from Hugh this is OK. It is
quite some time since I've looked into shmem.c.

> My intention was
> to simply start pageout() earlier to ensure the pages we tried to shrink
> were indeed being reclaimed.

Yes the intention is clear...

-- 
Michal Hocko
SUSE Labs