From: "Ihar 'Philips' Filipau" <filia@softhome.net>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.4.23-rc5
Date: Tue, 25 Nov 2003 17:34:18 +0100 [thread overview]
Message-ID: <3FC3848A.5010908@softhome.net> (raw)
In-Reply-To: <VK1t.6TB.1@gated-at.bofh.it>
Hi!
I was investigating memory allocation problems on my systems.
And I only figured out that I'm using quite up-to-date kernel - 2.4.22.
This is my post from another thread:
> Vanilla 2.4.22 (this is x86) (with HZ=1024, if it does matter).
>
> after '# echo -1 >/proc/sys/vm/overcommit_memory'
> 1. test app with memory touch still gets killed by
> oom_killer. (so no malloc() == NULL)
> 2. test app w/o memory touch still can happily allocate 2.8GB
> of memory (x86 - looks like 3/1 memory split) and only then
> gets NULL pointer - oom_killer is silent.
"overcommit_memory < 0" supposed to not allow apps to overallocate
memory - but still it works not like it is said in
Documentation/filesystems/proc.txt.
So apps which try to be MM friendly can silently break due to
very-very lazy memory allocation in kernel. Not nice when malloc() says
"everything is fine!".
[ Just checked: with overcommit==-1, as soon app trying to touch
those magic 2.8GB of memory, it gets killed by oom_killer. This is
totally wrong... ]
Probably fix docs at least... :-(
Marcelo Tosatti wrote:
>
> Hi,
>
> Yet another thing showed up (possible data corruption on x86-64), so here
> goes -rc5.
>
>
> Summary of changes from v2.4.23-rc4 to v2.4.23-rc5
> ============================================
>
> Andi Kleen:
> o Fix 32bit truncate64 on x86-64
>
> Marcelo Tosatti:
> o Felix Radensky: Remove debugging printk from agpgart
> o Changed EXTRAVERSION to -rc5
>
>
>
> -
> 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/
next parent reply other threads:[~2003-11-25 16:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <VK1t.6TB.1@gated-at.bofh.it>
2003-11-25 16:34 ` Ihar 'Philips' Filipau [this message]
[not found] <VOyg.w9.13@gated-at.bofh.it>
[not found] ` <VOyg.w9.11@gated-at.bofh.it>
2003-11-25 17:07 ` Linux 2.4.23-rc5 Pascal Schmidt
2003-11-26 9:18 ` Ihar 'Philips' Filipau
2003-11-25 17:15 ` Pascal Schmidt
2003-11-25 11:42 Marcelo Tosatti
2003-11-25 13:34 ` Marcos D. Marado Torres
2003-11-25 19:04 ` Mike Fedyk
2003-11-25 20:06 ` Marcelo Tosatti
2003-11-26 2:01 ` William Lee Irwin III
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=3FC3848A.5010908@softhome.net \
--to=filia@softhome.net \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
/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.