All of lore.kernel.org
 help / color / mirror / Atom feed
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/



       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.