All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Cameron Schaus <cam@schaus.ca>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.20 OOM with 8Gb RAM
Date: Thu, 12 Apr 2007 12:15:53 -0700	[thread overview]
Message-ID: <20070412121553.c7fd3249.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070412173830.GA31323@schaus.ca>

On Thu, 12 Apr 2007 11:38:30 -0600
Cameron Schaus <cam@schaus.ca> wrote:

> I am running the latest FC5-i686-smp kernel, 2.6.20, on a machine with
> 8Gb of RAM, and 2 Xeon processors.  The system has a 750Mb ramdisk,
> and one process allocating and deallocating memory that is also
> writing lots of files to the ramdisk.  The process also reads and
> writes from the network.  After the process runs for a while, the
> linux OOM killer starts killing processes, even though there is lots
> of memory available.
> 
> The system does not ordinarily use swap space, but I've added swap to
> see if it makes a difference, but it only defers the problem.
> 
> The OOM dump below shows that memory in the NORMAL_ZONE is exhausted,
> but there is still plenty of memory (6Gb+) in the HighMem Zone.  I can
> provide .config and dmesg data if these would be helpful.
> 
> Why is the OOM killer being invoked when there is still memory
> available for use?
> 
> java invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
> java invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
>  [<c0455f84>] out_of_memory+0x69/0x191
>  [<c0457460>] __alloc_pages+0x220/0x2aa
>  [<c046c80a>] cache_alloc_refill+0x26f/0x468
>  [<c046ca76>] __kmalloc+0x73/0x7d
>  [<c05bb4ce>] __alloc_skb+0x49/0xf7
>  [<c05e483d>] tcp_sendmsg+0x169/0xa04
>  [<c05fd76d>] inet_sendmsg+0x3b/0x45
>  [<c05b57d5>] sock_aio_write+0xf9/0x105
>  [<c0455708>] generic_file_aio_read+0x173/0x1a3
>  [<c046fd11>] do_sync_write+0xc7/0x10a
>  [<c04379fd>] autoremove_wake_function+0x0/0x35
>  [<c05e413e>] tcp_ioctl+0x10a/0x115
>  [<c05e4034>] tcp_ioctl+0x0/0x115
>  [<c05fd406>] inet_ioctl+0x8d/0x91
>  [<c0470564>] vfs_write+0xbc/0x154
>  [<c0470b62>] sys_write+0x41/0x67
>  [<c0403ef6>] sysenter_past_esp+0x5f/0x85

All of ZONE_NORMAL got used by ramdisk, and networking wants to
allocate a page from ZONE_NORMAL.  An oom-killing is the correct
response, although probably not effective.

ramdisk is a nasty thing - cannot you use ramfs or tmpfs?

  reply	other threads:[~2007-04-12 19:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-12 17:38 2.6.20 OOM with 8Gb RAM Cameron Schaus
2007-04-12 19:15 ` Andrew Morton [this message]
2007-04-12 21:30   ` Cameron Schaus
2007-04-13 22:39   ` Jason Lunz
2007-04-13 22:46     ` Andrew Morton
2007-04-13 22:54       ` William Lee Irwin III
2007-04-13 23:32         ` Andrew Morton
2007-04-13 23:40           ` William Lee Irwin III
2007-04-13 23:01       ` Jason Lunz

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=20070412121553.c7fd3249.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=cam@schaus.ca \
    --cc=linux-kernel@vger.kernel.org \
    /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.