linux-kernel - Re: Memory issues with Opteron 6220

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F3535E7.4000007@krogh.cc>
Date:	Fri, 10 Feb 2012 16:21:11 +0100
From:	Jesper Krogh <jesper@...gh.cc>
To:	Ingo Molnar <mingo@...e.hu>
CC:	linux-kernel@...r.kernel.org, jk@...ozymes.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Tejun Heo <tj@...nel.org>,
	herrmann.der.user@...glemail.com
Subject: Re: Memory issues with Opteron 6220

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/