From: Johannes Weiner <hannes@cmpxchg.org>
To: Andres Freund <andres@anarazel.de>,
Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 0/3] mm: support bigger cache workingsets and protect against writes
Date: Mon, 4 Apr 2016 13:13:35 -0400 [thread overview]
Message-ID: <1459790018-6630-1-git-send-email-hannes@cmpxchg.org> (raw)
Hi,
this is a follow-up to http://www.spinics.net/lists/linux-mm/msg101739.html
where Andres reported his database workingset being pushed out by the
minimum size enforcement of the inactive file list - currently 50% of cache
- as well as repeatedly written file pages that are never actually read.
Two changes fell out of the discussions. The first change observes that
pages that are only ever written don't benefit from caching beyond what the
writeback cache does for partial page writes, and so we shouldn't promote
them to the active file list where they compete with pages whose cached data
is actually accessed repeatedly. This change comes in two patches - one for
in-cache write accesses and one for refaults triggered by writes, neither of
which should promote a cache page.
Second, with the refault detection we don't need to set 50% of the cache
aside for used-once cache anymore since we can detect frequently used pages
even when they are evicted between accesses. We can allow the active list to
be bigger and thus protect a bigger workingset that isn't challenged by
streamers. Depending on the access patterns, this can increase major faults
during workingset transitions for better performance during stable phases.
Andres, I tried reproducing your postgres scenario, but I could never get
the WAL to interfere even with wal_log = hot_standby mode. It's a 8G
machine, I set shared_buffers = 2GB, ran pgbench -i -s 290, and then -c 32
-j 32 -M prepared -t 150000. Any input on how to trigger the thrashing you
observed would be appreciated. But it would be great if you could test these
patches on your known-problematic setup as well.
Thanks!
include/linux/memcontrol.h | 25 -----------
mm/filemap.c | 8 +++-
mm/page_alloc.c | 44 ------------------
mm/vmscan.c | 104 +++++++++++++++++--------------------------
4 files changed, 48 insertions(+), 133 deletions(-)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2016-04-04 17:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 17:13 Johannes Weiner [this message]
2016-04-04 17:13 ` [PATCH 1/3] mm: workingset: only do workingset activations on reads Johannes Weiner
2016-04-04 17:13 ` [PATCH 2/3] mm: filemap: only do access " Johannes Weiner
2016-04-04 21:22 ` Andrew Morton
2016-04-04 21:39 ` Rik van Riel
2016-04-04 21:55 ` Andrew Morton
2016-04-05 17:50 ` Johannes Weiner
2016-04-04 22:47 ` Johannes Weiner
2016-04-04 17:13 ` [PATCH 3/3] mm: vmscan: reduce size of inactive file list Johannes Weiner
2016-04-04 18:52 ` [PATCH 0/3] mm: support bigger cache workingsets and protect against writes Andres Freund
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=1459790018-6630-1-git-send-email-hannes@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=andres@anarazel.de \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
/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