From: Josh Berkus <josh@agliodbs.com>
To: Christoph Lameter <cl@linux.com>, Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Robert Haas <robertmhaas@gmail.com>,
Andres Freund <andres@2ndquadrant.com>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
sivanich@sgi.com
Subject: Re: [PATCH 0/2] Disable zone_reclaim_mode by default
Date: Tue, 08 Apr 2014 10:46:46 -0400 [thread overview]
Message-ID: <53440BD6.5030008@agliodbs.com> (raw)
In-Reply-To: <WM!ea1193ee171854a74828ee30c859d97ff2ce66405ffa3a0b8c31a1233c6a0b55530cdf3cbfcd989c0ec18fef1d533f81!@asav-3.01.com>
On 04/08/2014 10:17 AM, Christoph Lameter wrote:
> Another solution here would be to increase the threshhold so that
> 4 socket machines do not enable zone reclaim by default. The larger the
> NUMA system is the more memory is off node from the perspective of a
> processor and the larger the hit from remote memory.
8 and 16 socket machines aren't common for nonspecialist workloads
*now*, but by the time these changes make it into supported distribution
kernels, they may very well be. So having zone_reclaim_mode
automatically turn itself on if you have more than 8 sockets would still
be a booby-trap ("Boss, I dunno. I installed the additional processors
and memory performance went to hell!")
For zone_reclaim_mode=1 to be useful on standard servers, both of the
following need to be true:
1. the user has to have set CPU affinity for their applications;
2. the applications can't need more than one memory bank worth of cache.
The thing is, there is *no way* for Linux to know if the above is true.
Now, I can certainly imagine non-HPC workloads for which both of the
above would be true; for example, I've set up VMware ESX servers where
each VM has one socket and one memory bank. However, if the user knows
enough to set up socket affinity, they know enough to set
zone_reclaim_mode = 1. The default should cover the know-nothing case,
not the experienced specialist case.
I'd also argue that there's a fundamental false assumption in the entire
algorithm of zone_reclaim_mode, because there is no memory bank which is
as distant as disk is, ever. However, if it's off by default, then I
don't care.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
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 prev parent reply other threads:[~2014-04-08 14:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-07 22:34 Mel Gorman
2014-04-07 22:34 ` [PATCH 1/2] mm: " Mel Gorman
2014-04-07 23:35 ` Johannes Weiner
2014-04-08 1:17 ` Zhang Yanfei
2014-04-08 7:14 ` Andres Freund
2014-04-08 14:14 ` Christoph Lameter
2014-04-08 14:47 ` Mel Gorman
2014-04-07 22:34 ` [PATCH 2/2] mm: page_alloc: Do not cache reclaim distances Mel Gorman
2014-04-07 23:36 ` Johannes Weiner
2014-04-08 1:17 ` Zhang Yanfei
2014-04-08 7:26 ` [PATCH 0/2] Disable zone_reclaim_mode by default Vlastimil Babka
2014-04-08 14:17 ` Christoph Lameter
2014-04-08 14:26 ` Andres Freund
[not found] ` <WM!ea1193ee171854a74828ee30c859d97ff2ce66405ffa3a0b8c31a1233c6a0b55530cdf3cbfcd989c0ec18fef1d533f81!@asav-3.01.com>
2014-04-08 14:46 ` Josh Berkus [this message]
2014-04-08 19:53 ` Robert Haas
[not found] ` <WM!55d2a092da9f6180473043487a4eb612ae8195f78d2ffdd83f673ed5cb2cb9659cf61e0c8d5bae23f5c914057bcd2ee4!@asav-3.01.com>
2014-04-08 19:56 ` Josh Berkus
2014-04-09 13:08 ` Mel Gorman
2014-04-08 22:58 ` Christoph Lameter
2014-04-08 23:26 ` Mel Gorman
2014-04-10 10:26 ` Jeremy Harris
2014-04-18 15:49 ` Michal Hocko
2014-04-18 16:44 ` Christoph Lameter
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=53440BD6.5030008@agliodbs.com \
--to=josh@agliodbs.com \
--cc=akpm@linux-foundation.org \
--cc=andres@2ndquadrant.com \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=robertmhaas@gmail.com \
--cc=sivanich@sgi.com \
--cc=vbabka@suse.cz \
/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