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. My intention was to simply start pageout() earlier to ensure the pages we tried to shrink were indeed being reclaimed. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
