From: "Bron Gondwana" <brong@fastmail.fm>
To: "Christoph Lameter" <cl@linux.com>, "Robert Mueller" <robm@fastmail.fm>
Cc: "KOSAKI Motohiro" <kosaki.motohiro@jp.fujitsu.com>,
"Mel Gorman" <mel@csn.ul.ie>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"linux-mm" <linux-mm@kvack.org>
Subject: Re: Default zone_reclaim_mode = 1 on NUMA kernel is bad forfile/email/web servers
Date: Tue, 28 Sep 2010 22:42:20 +1000 [thread overview]
Message-ID: <1285677740.30176.1397281937@webmail.messagingengine.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1009280727370.4144@router.home>
On Tue, 28 Sep 2010 07:35 -0500, "Christoph Lameter" <cl@linux.com> wrote:
> > The problem we saw was purely with file caching. The application wasn't
> > actually allocating much memory itself, but it was reading lots of files
> > from disk (via mmap'ed memory mostly), and as most people would, we
> > expected that data would be cached in memory to reduce future reads from
> > disk. That was not happening.
>
> Obviously and you have stated that numerous times. Problem that the use
> of
> a remote memory will reduced performance of reads so the OS (with
> zone_reclaim=1) defaults to the use of local memory and favors reclaim of
> local memory over the allocation from the remote node. This is fine if
> you have multiple applications running on both nodes because then each
> application will get memory local to it and therefore run faster. That
> does not work with a single app that only allocates from one node.
Is this what's happening, or is IO actually coming from disk in preference
to the remote node? I can certainly see the logic behind preferring to
reclaim the local node if that's all that's happening - though the OS should
be allocating the different tasks more evenly across the nodes in that case.
> Control over memory allocations over the various nodes under NUMA
> for a process can occur via the numactl ctl or the libnuma C apis.
>
> F.e.e
>
> numactl --interleave ... command
>
> will address that issue for a specific command that needs to go
Gosh what a pain. While it won't kill us too much to add to our
startup, it does feel a lot like the tail is wagging the dog from here
still. A task that doesn't ask for anything special should get sane
defaults, and the cost of data from the other node should be a lot
less than the cost of the same data from spinning rust.
Bron.
--
Bron Gondwana
brong@fastmail.fm
WARNING: multiple messages have this Message-ID (diff)
From: "Bron Gondwana" <brong@fastmail.fm>
To: Christoph Lameter <cl@linux.com>, Robert Mueller <robm@fastmail.fm>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mel Gorman <mel@csn.ul.ie>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: Default zone_reclaim_mode = 1 on NUMA kernel is bad forfile/email/web servers
Date: Tue, 28 Sep 2010 22:42:20 +1000 [thread overview]
Message-ID: <1285677740.30176.1397281937@webmail.messagingengine.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1009280727370.4144@router.home>
On Tue, 28 Sep 2010 07:35 -0500, "Christoph Lameter" <cl@linux.com> wrote:
> > The problem we saw was purely with file caching. The application wasn't
> > actually allocating much memory itself, but it was reading lots of files
> > from disk (via mmap'ed memory mostly), and as most people would, we
> > expected that data would be cached in memory to reduce future reads from
> > disk. That was not happening.
>
> Obviously and you have stated that numerous times. Problem that the use
> of
> a remote memory will reduced performance of reads so the OS (with
> zone_reclaim=1) defaults to the use of local memory and favors reclaim of
> local memory over the allocation from the remote node. This is fine if
> you have multiple applications running on both nodes because then each
> application will get memory local to it and therefore run faster. That
> does not work with a single app that only allocates from one node.
Is this what's happening, or is IO actually coming from disk in preference
to the remote node? I can certainly see the logic behind preferring to
reclaim the local node if that's all that's happening - though the OS should
be allocating the different tasks more evenly across the nodes in that case.
> Control over memory allocations over the various nodes under NUMA
> for a process can occur via the numactl ctl or the libnuma C apis.
>
> F.e.e
>
> numactl --interleave ... command
>
> will address that issue for a specific command that needs to go
Gosh what a pain. While it won't kill us too much to add to our
startup, it does feel a lot like the tail is wagging the dog from here
still. A task that doesn't ask for anything special should get sane
defaults, and the cost of data from the other node should be a lot
less than the cost of the same data from spinning rust.
Bron.
--
Bron Gondwana
brong@fastmail.fm
--
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:[~2010-09-28 12:51 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-13 3:39 Default zone_reclaim_mode = 1 on NUMA kernel is bad for file/email/web servers Robert Mueller
2010-09-16 10:01 ` KOSAKI Motohiro
2010-09-16 10:01 ` KOSAKI Motohiro
2010-09-16 17:06 ` Christoph Lameter
2010-09-16 17:06 ` Christoph Lameter
2010-09-17 0:50 ` Robert Mueller
2010-09-17 0:50 ` Robert Mueller
2010-09-17 6:01 ` Shaohua Li
2010-09-17 6:01 ` Shaohua Li
2010-09-17 7:32 ` Robert Mueller
2010-09-17 7:32 ` Robert Mueller
2010-09-17 13:56 ` Christoph Lameter
2010-09-17 13:56 ` Christoph Lameter
2010-09-17 14:09 ` Bron Gondwana
2010-09-17 14:09 ` Bron Gondwana
2010-09-17 14:22 ` Christoph Lameter
2010-09-17 14:22 ` Christoph Lameter
2010-09-17 23:01 ` Bron Gondwana
2010-09-17 23:01 ` Bron Gondwana
2010-09-20 9:34 ` Mel Gorman
2010-09-20 9:34 ` Mel Gorman
2010-09-20 23:41 ` Default zone_reclaim_mode = 1 on NUMA kernel is bad forfile/email/web servers Rob Mueller
2010-09-20 23:41 ` Rob Mueller
2010-09-21 9:04 ` Mel Gorman
2010-09-21 9:04 ` Mel Gorman
2010-09-21 14:14 ` Christoph Lameter
2010-09-21 14:14 ` Christoph Lameter
2010-09-22 3:44 ` Rob Mueller
2010-09-22 3:44 ` Rob Mueller
2010-09-27 2:01 ` KOSAKI Motohiro
2010-09-27 2:01 ` KOSAKI Motohiro
2010-09-27 13:53 ` Christoph Lameter
2010-09-27 13:53 ` Christoph Lameter
2010-09-27 23:17 ` Robert Mueller
2010-09-27 23:17 ` Robert Mueller
2010-09-28 12:35 ` Christoph Lameter
2010-09-28 12:35 ` Christoph Lameter
2010-09-28 12:42 ` Bron Gondwana [this message]
2010-09-28 12:42 ` Bron Gondwana
2010-09-28 12:49 ` Christoph Lameter
2010-09-28 12:49 ` Christoph Lameter
2010-09-30 7:05 ` Andi Kleen
2010-09-30 7:05 ` Andi Kleen
2010-10-04 12:45 ` KOSAKI Motohiro
2010-10-04 12:45 ` KOSAKI Motohiro
2010-10-04 13:07 ` Christoph Lameter
2010-10-04 13:07 ` Christoph Lameter
2010-10-05 5:32 ` KOSAKI Motohiro
2010-10-05 5:32 ` KOSAKI Motohiro
2010-10-04 19:43 ` David Rientjes
2010-10-04 19:43 ` David Rientjes
2010-09-21 1:05 ` Default zone_reclaim_mode = 1 on NUMA kernel is bad for file/email/web servers KAMEZAWA Hiroyuki
2010-09-21 1:05 ` KAMEZAWA Hiroyuki
2010-09-27 2:04 ` KOSAKI Motohiro
2010-09-27 2:04 ` KOSAKI Motohiro
2010-09-27 2:06 ` KAMEZAWA Hiroyuki
2010-09-27 2:06 ` KAMEZAWA Hiroyuki
2010-09-23 11:44 ` Balbir Singh
2010-09-23 11:44 ` Balbir Singh
2010-09-30 8:38 ` Bron Gondwana
2010-09-30 8:38 ` Bron Gondwana
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=1285677740.30176.1397281937@webmail.messagingengine.com \
--to=brong@fastmail.fm \
--cc=cl@linux.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=robm@fastmail.fm \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.