From: Robin Holt <holt@sgi.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Robin Holt <holt@sgi.com>, LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 4/4] zone_reclaim_mode is always 0 by default
Date: Thu, 21 May 2009 08:57:30 -0500 [thread overview]
Message-ID: <20090521135730.GA7581@sgi.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0905210924520.31888@qirst.com>
On Thu, May 21, 2009 at 09:31:08AM -0400, Christoph Lameter wrote:
> On Thu, 21 May 2009, KOSAKI Motohiro wrote:
>
> > I can't catch up your message. Can you post your patch?
> > Can you explain your sanity check?
> >
> > Now, I decide to remove "nr_online_nodes >= 4" condition.
> > Apache regression is really non-sense.
>
> Not sure what that means? Apache regresses with zone reclaim? My
> measurements when we introduced zone reclaim showed just the opposite
> because Apache would get node local memory and thus run faster. You can
> screw this up of course if you load the system so high that the apache
> processes are tossed around by the scheduler. Then the node local
> allocation may be worse than round robin because all the pages allocated
> by a process are now on one node if the scheduler moves the
> process to a remote node then all accesses are penalized.
I think the point Kosaki is trying to make is that reclaim happens really
aggressively for processes on node 0 versus node 1. Maybe I am clinging
too strongly to one of the earlier posts, but that is what I read between
the lines.
That frequent reclaim is impacting allocations when he would rather they
skip the reclaim and go off node. Again, it sounds like he prefers tuning
the default to what works best for him. I don't too strongly disagree,
as long as the default isn't being changed capriciously.
I have always expected that NUMA boxes had reasons for preferring node
locality. Maybe I misunderstand. Maybe Ci7 is special and does not
have any impact for off socket references. I would be surprised by that
after reading to literature, but I have not tested latency or bandwidth
on one so I can not say.
Personally, it sounds like if I had a box configured as his is, I would
use a cpuset to restrict most memory hungry things from using cpus
on node 0 and leave that as the small 'junk processes' cpu. Maybe even
restrict things like cron etc to that corner of the system.
Thanks,
Robin
--
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:[~2009-05-21 13:56 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-13 3:06 [PATCH 0/4] various zone_reclaim cleanup KOSAKI Motohiro
2009-05-13 3:06 ` [PATCH 1/4] vmscan: change the number of the unmapped files in zone reclaim KOSAKI Motohiro
2009-05-13 13:31 ` Rik van Riel
2009-05-14 19:52 ` Christoph Lameter
2009-05-18 3:15 ` Wu Fengguang
2009-05-18 3:35 ` KOSAKI Motohiro
2009-05-18 3:53 ` Wu Fengguang
2009-05-19 1:11 ` KOSAKI Motohiro
2009-05-13 3:06 ` [PATCH 2/4] vmscan: drop PF_SWAPWRITE from zone_reclaim KOSAKI Motohiro
2009-05-13 13:35 ` Rik van Riel
2009-05-14 19:57 ` Christoph Lameter
2009-05-18 3:33 ` Wu Fengguang
2009-05-13 3:07 ` [PATCH 3/4] vmscan: zone_reclaim use may_swap KOSAKI Motohiro
2009-05-13 11:26 ` Johannes Weiner
2009-05-13 14:43 ` Rik van Riel
2009-05-14 19:59 ` Christoph Lameter
2009-05-18 3:35 ` Wu Fengguang
2009-05-13 3:08 ` [PATCH 4/4] zone_reclaim_mode is always 0 by default KOSAKI Motohiro
2009-05-13 14:47 ` Rik van Riel
2009-05-14 8:20 ` KOSAKI Motohiro
2009-05-14 11:48 ` Robin Holt
2009-05-14 12:02 ` KOSAKI Motohiro
2009-05-13 15:22 ` Robin Holt
2009-05-14 20:05 ` Christoph Lameter
2009-05-14 20:23 ` Rik van Riel
2009-05-14 20:31 ` Christoph Lameter
2009-05-15 1:02 ` KOSAKI Motohiro
2009-05-15 10:51 ` Robin Holt
2009-05-19 2:53 ` KOSAKI Motohiro
2009-05-20 14:00 ` Robin Holt
2009-05-21 2:44 ` KOSAKI Motohiro
2009-05-21 13:31 ` Christoph Lameter
2009-05-21 13:57 ` Robin Holt [this message]
2009-05-24 13:44 ` KOSAKI Motohiro
2009-05-15 18:01 ` Christoph Lameter
2009-05-18 3:49 ` Wu Fengguang
2009-05-19 1:16 ` Zhang, Yanmin
2009-05-19 2:53 ` KOSAKI Motohiro
2009-05-19 2:57 ` KOSAKI Motohiro
2009-05-19 3:38 ` Zhang, Yanmin
2009-05-19 4:30 ` KOSAKI Motohiro
2009-05-19 5:06 ` Zhang, Yanmin
2009-05-19 7:09 ` KOSAKI Motohiro
2009-05-19 7:15 ` Zhang, Yanmin
2009-05-18 9:09 ` Wu Fengguang
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=20090521135730.GA7581@sgi.com \
--to=holt@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.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