linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Rob Mueller <robm@fastmail.fm>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, Bron Gondwana <brong@fastmail.fm>,
	linux-mm <linux-mm@kvack.org>,
	Christoph Lameter <cl@linux-foundation.org>
Subject: Re: Default zone_reclaim_mode = 1 on NUMA kernel is bad forfile/email/web servers
Date: Tue, 21 Sep 2010 10:04:07 +0100	[thread overview]
Message-ID: <20100921090407.GA11439@csn.ul.ie> (raw)
In-Reply-To: <52C8765522A740A4A5C027E8FDFFDFE3@jem>

On Tue, Sep 21, 2010 at 09:41:21AM +1000, Rob Mueller wrote:
>> I don't think we will ever get the default value for this tunable right.
>> I would also worry that avoiding the reclaim_mode for file-backed
>> cache will hurt HPC applications that are dumping their data to disk
>> and depending on the existing default for zone_reclaim_mode to not
>> pollute other nodes.
>>
>> The ideal would be if distribution packages for mail, web servers
>> and others that are heavily IO orientated would prompt for a change
>> to the default value of zone_reclaim_mode in sysctl.
>
> I would argue that there's a lot more mail/web/file servers out there 
> than HPC machines. And HPC machines tend to have a team of people to  
> monitor/tweak them. I think it would be much more sane to default this to 
> 0 which works best for most people, and get the HPC people to change it.
>

No doubt this is true. The only real difference is that there are more NUMA
machines running mail/web/file servers now than there might have been in the
past. The default made sense once upon a time. Personally I wouldn't mind
the default changing but my preference would be that distribution packages
installing on NUMA machines would prompt if the default should be changed if it
is likely to be of benefit for that package (e.g. the mail, file and web ones).

> However there's still another question, why is this problem happening at 
> all for us? I know almost nothing about NUMA, but from other posts, it 
> sounds like the problem is the memory allocations are all happening on 
> one node?

Yes.

> But I don't understand why that would be happening.

Because in a situation where you have many NUMA-aware applications
running bound to CPUs, it performs better if they always allocate from
local nodes instead of accessing remote nodes. It's great for one type
of workload but not so much for mail/web/file.

> The machine 
> runs the cyrus IMAP server, which is a classic unix forking server with 
> 1000's of processes. Each process will mmap lots of different files to 
> access them. Why would that all be happening on one node, not spread 
> around?
>

Honestly, I don't know and I don't have such a machine to investigate
with. My guess is that there are a number of files that are hot and
accessed by multiple processes on different nodes and they are evicting
each other but it's only a guess.

> One thing is that the machine is vastly more IO loaded than CPU loaded, 
> in fact it uses very little CPU at all (a few % usually). Does the kernel 
> prefer to run processes on one particular node if it's available?

It prefers to run on the same node it ran previously. If they all
happened to start up on a small subset of nodes, they could be
continually getting running there.

> So if a 
> machine has very little CPU load, every process will generally end up  
> running on the same node?
>

It's possible they are running on a small subset. mpstat should be able
to give a basic idea of what the spread across CPUs is.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
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>

  reply	other threads:[~2010-09-21  9:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1284349152.15254.1394658481@webmail.messagingengine.com>
2010-09-16 10:01 ` Default zone_reclaim_mode = 1 on NUMA kernel is bad for file/email/web servers KOSAKI Motohiro
2010-09-16 17:06   ` Christoph Lameter
2010-09-17  0:50     ` Robert Mueller
2010-09-17  6:01       ` Shaohua Li
2010-09-17  7:32         ` Robert Mueller
2010-09-17 13:56           ` Christoph Lameter
2010-09-17 14:09             ` Bron Gondwana
2010-09-17 14:22               ` Christoph Lameter
2010-09-17 23:01                 ` Bron Gondwana
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-21  9:04       ` Mel Gorman [this message]
2010-09-21 14:14         ` Christoph Lameter
2010-09-22  3:44           ` Rob Mueller
2010-09-27  2:01         ` KOSAKI Motohiro
2010-09-27 13:53           ` Christoph Lameter
2010-09-27 23:17             ` Robert Mueller
2010-09-28 12:35               ` Christoph Lameter
2010-09-28 12:42                 ` Bron Gondwana
2010-09-28 12:49                   ` Christoph Lameter
2010-09-30  7:05             ` Andi Kleen
2010-10-04 12:45             ` KOSAKI Motohiro
2010-10-04 13:07               ` Christoph Lameter
2010-10-05  5:32                 ` KOSAKI Motohiro
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-27  2:04     ` KOSAKI Motohiro
2010-09-27  2:06       ` KAMEZAWA Hiroyuki
2010-09-23 11:44   ` Balbir Singh
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=20100921090407.GA11439@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=brong@fastmail.fm \
    --cc=cl@linux-foundation.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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 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).