All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Krogh <jesper@krogh.cc>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, jk@novozymes.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Yinghai Lu <yinghai@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, Tejun Heo <tj@kernel.org>,
	herrmann.der.user@googlemail.com
Subject: Re: Memory issues with Opteron 6220
Date: Fri, 10 Feb 2012 16:21:11 +0100	[thread overview]
Message-ID: <4F3535E7.4000007@krogh.cc> (raw)
In-Reply-To: <4F343582.7080007@krogh.cc>

Long story short, this is a red herring.

The system we migrated the configuration from had
vm.overcommit_memory => 2, so then the new
one got that too. (50% actual memory + swap)

That worked fine.. We set it back in 2008 due to the
heuristic version not doing the correct thing. What
has happened over the years is that the memory grow
and swap/memory ration has gone smaller, both due
to memory growth and swap being more and more irellevant.

So the new system was set up with reduced swap 8GB vs. 100GB
which mean that the algorithm used by overcommit_memory
ended up not allowing more than: 64GB+8GB of memory being
used (less than physical memory).. The system migrated from would
by this rule allow 64+100GB, this fitting quite ok.

I guess it took so long to realize, since something with "overcommit"
isn't what springs into mind when you dont think you're even
close to be there, combined with the mis-leading power-saving issue
that just confused the problem.

I would admit that we could have saved a significant of time/fustration
if dmesg had revealed a message that it was the overcommit limits being
hit and thus knocking off the processes.

Another change to suggest would be to not kill off processes due
to overcommit at least before actual memory size had been reached.

But, long story short, system misconfiguration..

-- 
Jesper

  reply	other threads:[~2012-02-10 15:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08 14:37 Memory issues with Opteron 6220 Anders Ossowicki
2012-02-09  8:33 ` Ingo Molnar
2012-02-09  9:08   ` Eric Dumazet
2012-02-09 13:23     ` Ingo Molnar
2012-02-09 21:07   ` Jesper Krogh
2012-02-10 15:21     ` Jesper Krogh [this message]
2012-02-11 13:48       ` Ingo Molnar
2012-02-14  9:32         ` Anders Ossowicki
     [not found] ` <20120208205628.GA18909@alberich.amd.com>
2012-02-09 12:43   ` Anders Ossowicki
2012-02-09 13:28     ` Ingo Molnar
2012-02-09 13:49       ` Anders Ossowicki
2012-02-09 16:11         ` Yinghai Lu
2012-02-09 17:51           ` Anders Ossowicki
2012-02-09 18:56             ` Yinghai Lu
2012-02-11 13:50               ` Ingo Molnar

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=4F3535E7.4000007@krogh.cc \
    --to=jesper@krogh.cc \
    --cc=akpm@linux-foundation.org \
    --cc=herrmann.der.user@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=jk@novozymes.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=yinghai@kernel.org \
    /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.