Re: [PATCH v2 5/5] drm/i915: Start writeback from the shrinker

From: Michal Hocko <mhocko@suse.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, Hugh Dickins <hughd@google.com>,
	Matthew Auld <matthew.auld@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH v2 5/5] drm/i915: Start writeback from the shrinker
Date: Fri, 9 Jun 2017 15:35:58 +0200	[thread overview]
Message-ID: <20170609133558.GG21764@dhcp22.suse.cz> (raw)
In-Reply-To: <149700911784.23435.5596315979107409786@mail.alporthouse.com>

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