On Sun, Jun 08, 2014 at 03:03:15AM +0100, Ben Hutchings wrote:
> On Wed, 2014-06-04 at 16:22 -0700, Greg Kroah-Hartman wrote:
> > 3.14-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Johannes Weiner <han...@cmpxchg.org>
> >
> > commit 623762517e2370be3b3f95f4fe08d6c063a49b06 upstream.
> >
> > This reverts commit 0bf1457f0cfc ("mm: vmscan: do not swap anon pages
> > just because free+file is low") because it introduced a regression in
> > mostly-anonymous workloads, where reclaim would become ineffective and
> > trap every allocating task in direct reclaim.
> [...]
>
> That commit was not included in 3.14 or in subsequent stable updates, so
> this 'revert' is not approriate. We now have duplicate checks:
>
> /*
> * If it's foreseeable that reclaiming the file cache won't be
> * enough to get the zone back into a desirable shape, we have
> * to swap. Better start now and leave the - probably heavily
> * thrashing - remaining file pages alone.
> */
> if (global_reclaim(sc)) {
> free = zone_page_state(zone, NR_FREE_PAGES);
> if (unlikely(file + free <= high_wmark_pages(zone))) {
> scan_balance = SCAN_ANON;
> goto out;
> }
> }
>
> /*
> * Prevent the reclaimer from falling into the cache trap: as
> * cache pages start out inactive, every cache fault will tip
> * the scan balance towards the file LRU. And as the file LRU
> * shrinks, so does the window for rotation from references.
> * This means we have a runaway feedback loop where a tiny
> * thrashing file LRU becomes infinitely more attractive than
> * anon pages. Try to detect this based on file LRU size.
> */
> if (global_reclaim(sc)) {
> unsigned long free = zone_page_state(zone, NR_FREE_PAGES);
>
> if (unlikely(file + free <= high_wmark_pages(zone))) {
> scan_balance = SCAN_ANON;
> goto out;
> }
> }
>
> Ben.
Ugh, good catch, thanks for this. I'll go revert it now.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
