Re: Overcommit problems with 2.6.12-rc4 (on AMD64)

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Iau, 2005-06-02 at 11:18, Steinar H. Gunderson wrote:
>   imapd[31528]: segfault at 00000000fff00000 rip 00000000556a1a6d rsp 00000000ffffd394 error 4
>   imapd[31527]: segfault at 00000000fff00000 rip 00000000556a1a6d rsp 00000000ffffcbe4 error 4
>   sh[31530]: segfault at 00000000ffff7ff4 rip 000000005555e556 rsp 00000000ffff7ff8 error 6
>   sh[31531]: segfault at 00000000ffff7e5c rip 00000000555dc575 rsp 00000000ffff7e60 error 6
>   Unable to load interpreter /lib/ld-linux.so.2
>   Unable to load interpreter /lib/ld-linux.so.2
>   (ad infinitum)

You ran out of address space

> Suddenly everything seems to be back to normal (ie. we could swapoff, and the
> programs stopped running out of memory; no changes in the cache used,
> though), and after a quick restart of services, everything is back to normal.
> So to me, it looks like vm.overcommit_memory=2 is broken, at least on AMD64.
> Any ideas why this would happen?

vm.overcommit_memory=2 prevents the possibility of overcommitting - ie
of address space being allocated to someone which is not used. Your swap
allocation data is showing pages allocated not pages that could be
allocated due to page faults. You need to look as the AS figures in
/proc/meminfo to see the address space committed.

Basically it went back to "sane" because you said "ok I might get OOM
but take the gamble", and since many programs allocate lots of space
they never touch it worked.

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