Red Hat Bugzilla – Bug 224600
running 32-bit executables on x86_64/ia64/s390x causes negative "vm_committed_space" value
Last modified: 2007-11-16 20:14:46 EST
+++ This bug was initially created as a clone of Bug #218757 +++
Description of problem:
Centos user found problems with vm accounting and noted it appeared to be fixed
upstream but not in Centos (and it seems not in RHEL either)
-- Additional comment from email@example.com on 2006-12-26 12:18 EST --
We have seen this VM accounting bug on kernel 2.6.9-42.0.2.ELsmp for x86_64 (but
it does not seem to be fixed in the latest revision either). In particular,
vm.overcommit was set to 2, and the machines (which run a lot of short i386
binaries at high frequencies) refused to fork any more processes -- malloc() was
failing. After killing all user processes, Committed_AS was still well over 8
GB, clearly an accounting leak.
Please make this a relatively high priority, as overcommit features on x86_64 is
essentially broken without it (we have set it to 0 for now).
-- Additional comment from firstname.lastname@example.org on 2007-01-26 05:46 EST --
Also reported as affecting RHEL3
-- Additional comment from email@example.com on 2007-01-26 10:55 EST --
This is a fairly serious bug, if we consider that people turn on strict memory
overcommit exactly because of increased server stability in the long run.
Note that this problem (i.e., negative "vm_committed_space" value) is only
cosmetic (bogus /proc/meminfo "Committed_AS" value) when the system is booted
with the default setting for /proc/sys/vm/overcommit_memory. It is only when
the "overcommit_memory" sysctl value has been set to 2 that the kernel will
alter its behavior based on the "vm_committed_space" value.
If a customer is experiencing ENOMEM errors in user-space programs on a system
with "overcommit_memory" set to 2, a work-around would be to use the default
In the case of RHEL3 (unlike RHEL4), running a 32-bit executable on x86_64
results in decrementing the "Committed_AS" value by the initial stack size.
This is because no call to vm_enough_memory() was made in ia32_setup_arg_pages().
Since I'm working on the RHEL4 case, I'll reassign this RHEL3 bug to myself.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
I'm changing the subject line to reflect what the real problem is in RHEL3,
which exists on the x86_64, ia64, and s390x arches (in 32-bit exec support).
Note that the upstream changes indicated in the "GIT commit" link in the
initial comment of this bug report do not address the RHEL3 problem, which
is causing the kernel's "vm_committed_space" global variable to go backwards
until it wraps to a negative value (and then later interpreted as a very
large unsigned value).
Note that this problem does not exist in RHEL4. (But RHEL4 has a different
problem in maintaining the "vm_committed_space" global variable.)
Patch posted for internal review on 31-Jan-2007.
A fix for this problem has just been committed to the RHEL3 U9
patch pool this evening (in kernel version 2.4.21-47.5.EL).
QE ack for RHEL3.9.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
Internal Status set to 'Resolved'
Status set to: Closed by Client
This event sent from IssueTracker by yves.begrand