linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Kuo-Hsin Yang <vovoy@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Minchan Kim <minchan@kernel.org>,
	Sonny Rao <sonnyrao@chromium.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] mm: vmscan: scan anonymous pages on file refaults
Date: Fri, 12 Jul 2019 09:13:59 +0200	[thread overview]
Message-ID: <20190712071359.GN29483@dhcp22.suse.cz> (raw)
In-Reply-To: <20190705124505.GA173726@google.com>

On Fri 05-07-19 20:45:05, Kuo-Hsin Yang wrote:
> With 4 processes accessing non-overlapping parts of a large file, 30316
> pages swapped out with this patch, 5152 pages swapped out without this
> patch. The swapout number is small comparing to pgpgin.

which is 5 times more swapout. This may be seen to be a lot for
workloads that prefer no swapping (e.g. large in memory databases) with
an occasional heavy IO (e.g. backup). And I am worried those would
regress. I do agree that the current behavior is far from optimal
because the trashing is real. I believe that we really need a different
approach. Johannes has brought this up few years back (sorry I do not
have a link handy) but it was essentially about implementing refault
logic to anonymous memory and swap out based on the refault price. If
there is effectively no swapin then it simply makes more sense to swap
out rather than refault a page cache.

That being said, I am not nacking the patch. Let's see whether something
regresses as there is a no clear cut for the proper behavior. But I am
bringing that up because we really need a better and more robust plan
for the future.

-- 
Michal Hocko
SUSE Labs


      reply	other threads:[~2019-07-12  7:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19  8:08 [PATCH] mm: vmscan: fix not scanning anonymous pages when detecting file refaults Kuo-Hsin Yang
2019-06-27  4:03 ` Andrew Morton
2019-06-27 18:41 ` Johannes Weiner
2019-06-28  6:51   ` Minchan Kim
2019-06-28  8:44     ` Vovo Yang
2019-06-28 14:22     ` Johannes Weiner
2019-06-28 23:34       ` Minchan Kim
2019-06-28  6:58 ` Minchan Kim
2019-06-28 11:16 ` [PATCH v2] " Kuo-Hsin Yang
2019-06-28 14:32   ` Johannes Weiner
2019-06-28 23:36     ` Minchan Kim
2019-07-01  7:56     ` Kuo-Hsin Yang
2019-07-01  8:10   ` [PATCH] mm: vmscan: scan anonymous pages on " Kuo-Hsin Yang
2019-07-03 14:30     ` Michal Hocko
2019-07-04  9:47       ` Kuo-Hsin Yang
2019-07-04 11:04         ` Michal Hocko
2019-07-05 12:45           ` Kuo-Hsin Yang
2019-07-12  7:13             ` Michal Hocko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190712071359.GN29483@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=sonnyrao@chromium.org \
    --cc=stable@vger.kernel.org \
    --cc=vovoy@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).