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?
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox