From: Jonathan Miles <jon@cybus.co.uk>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: OOM kernel behaviour
Date: Tue, 01 Dec 2009 13:21:38 +0000 [thread overview]
Message-ID: <4B151862.9020201@cybus.co.uk> (raw)
In-Reply-To: <4B14E8A2.4020500@cybus.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
On 01/12/09 09:57 Jonathan Miles said the following:
> I've attached a good example which shows Xorg invoking the OOM killer
> when the page-cache is using ~1.3GB out of 2GB. My understanding from
> reading linux-mm.org is that the kernel actually prefers to swap than
> reclaim from the page-cache... is this accurate? However, what if there
> is no swap, or it's configured not to use it? Should the kernel then try
> to reclaim instead?
And here's another (attached), with a slightly different initial code
path, where hald has caused the OOM killer to be invoked even though
(again) there was ~1.3GB out of 2GB used by the page-cache.
[66568.252937] Call Trace:
[66568.252963] [<c01b5a0f>] oom_kill_process+0x9f/0x250
[66568.252981] [<c01b601e>] ? select_bad_process+0xbe/0xf0
[66568.252989] [<c01b60a1>] __out_of_memory+0x51/0xa0
[66568.252997] [<c01b6143>] out_of_memory+0x53/0xb0
[66568.253045] [<c01b83fe>] __alloc_pages_slowpath+0x42e/0x480
[66568.253055] [<c01b855f>] __alloc_pages_nodemask+0x10f/0x120
[66568.253077] [<c01ca076>] do_anonymous_page+0x66/0x200
...
Hopefully I'll get some time to RTFS, but at the moment I'm trying to
understand whether or not this is *intended* behaviour. When there's no
swap available, should the kernel be calling the OOM killer instead of
trying to reclaim memory from buffers/cache?
Thanks,
--
Jonathan Miles <jon@cybus.co.uk>
http://www.linkedin.com/in/jonmiles
[-- Attachment #2: OOM2.txt --]
[-- Type: text/plain, Size: 3694 bytes --]
[66568.252903] hald invoked oom-killer: gfp_mask=0x280da, order=0, oomkilladj=0
[66568.252924] hald cpuset=/ mems_allowed=0
[66568.252931] Pid: 844, comm: hald Not tainted 2.6.31-14-generic #48-Ubuntu
[66568.252937] Call Trace:
[66568.252963] [<c01b5a0f>] oom_kill_process+0x9f/0x250
[66568.252981] [<c01b601e>] ? select_bad_process+0xbe/0xf0
[66568.252989] [<c01b60a1>] __out_of_memory+0x51/0xa0
[66568.252997] [<c01b6143>] out_of_memory+0x53/0xb0
[66568.253045] [<c01b83fe>] __alloc_pages_slowpath+0x42e/0x480
[66568.253055] [<c01b855f>] __alloc_pages_nodemask+0x10f/0x120
[66568.253077] [<c01ca076>] do_anonymous_page+0x66/0x200
[66568.253086] [<c012d3cd>] ? kmap_atomic_prot+0xcd/0xf0
[66568.253093] [<c01cc460>] handle_mm_fault+0x330/0x380
[66568.253116] [<c0317c58>] ? vsnprintf+0xc8/0x400
[66568.253128] [<c0572cf8>] do_page_fault+0x148/0x380
[66568.253150] [<c0572bb0>] ? do_page_fault+0x0/0x380
[66568.253160] [<c0570be3>] error_code+0x73/0x80
[66568.253181] [<c0318f06>] ? copy_to_user+0x116/0x120
[66568.253194] [<c02025e7>] simple_read_from_buffer+0x67/0xb0
[66568.253217] [<c023940f>] sysfs_read_file+0x4f/0x80
[66568.253239] [<c01e78b7>] vfs_read+0x97/0x190
[66568.253249] [<c02393c0>] ? sysfs_read_file+0x0/0x80
[66568.253270] [<c01e7ecd>] sys_read+0x3d/0x70
[66568.253281] [<c010336c>] syscall_call+0x7/0xb
[66568.253289] Mem-Info:
[66568.253305] DMA per-cpu:
[66568.253311] CPU 0: hi: 0, btch: 1 usd: 0
[66568.253319] CPU 1: hi: 0, btch: 1 usd: 0
[66568.253336] Normal per-cpu:
[66568.253343] CPU 0: hi: 186, btch: 31 usd: 181
[66568.253351] CPU 1: hi: 186, btch: 31 usd: 80
[66568.253367] HighMem per-cpu:
[66568.253373] CPU 0: hi: 186, btch: 31 usd: 35
[66568.253380] CPU 1: hi: 186, btch: 31 usd: 133
[66568.253402] Active_anon:174534 active_file:116377 inactive_anon:63691
[66568.253408] inactive_file:118428 unevictable:0 dirty:0 writeback:0 unstable:0
[66568.253413] free:12183 slab:8778 mapped:71864 pagetables:2711 bounce:0
[66568.253437] DMA free:8076kB min:64kB low:80kB high:96kB active_anon:236kB inactive_anon:256kB active_file:0kB inactive_file:56kB unevictable:0kB present:15852kB pages_scanned:504 all_unreclaimable? no
[66568.253463] lowmem_reserve[]: 0 865 2007 2007
[66568.253493] Normal free:40184kB min:3728kB low:4660kB high:5592kB active_anon:196728kB inactive_anon:60324kB active_file:248012kB inactive_file:248492kB unevictable:0kB present:885944kB pages_scanned:1232480 all_unreclaimable? no
[66568.253510] lowmem_reserve[]: 0 0 9134 9134
[66568.253538] HighMem free:472kB min:512kB low:1740kB high:2972kB active_anon:501172kB inactive_anon:194184kB active_file:217496kB inactive_file:225164kB unevictable:0kB present:1169244kB pages_scanned:1912736 all_unreclaimable? yes
[66568.253565] lowmem_reserve[]: 0 0 0 0
[66568.253588] DMA: 3*4kB 4*8kB 2*16kB 2*32kB 4*64kB 2*128kB 3*256kB 1*512kB 2*1024kB 0*2048kB 1*4096kB = 8076kB
[66568.253631] Normal: 9050*4kB 0*8kB 1*16kB 2*32kB 3*64kB 1*128kB 0*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 40184kB
[66568.253671] HighMem: 2*4kB 54*8kB 2*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 472kB
[66568.253721] 340269 total pagecache pages
[66568.253727] 0 pages in swap cache
[66568.253734] Swap cache stats: add 0, delete 0, find 0/0
[66568.253752] Free swap = 0kB
[66568.253757] Total swap = 0kB
[66568.277410] 521939 pages RAM
[66568.277413] 294613 pages HighMem
[66568.277414] 8809 pages reserved
[66568.277416] 378515 pages shared
[66568.277418] 259136 pages non-shared
[66568.277431] Out of memory: kill process 7811 (run-mozilla.sh) score 169511 or a child
[66568.277508] Killed process 7815 (thunderbird-bin)
next prev parent reply other threads:[~2009-12-01 13:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-30 17:38 OOM kernel behaviour Jonathan Miles
2009-11-30 18:57 ` Christoph Lameter
2009-12-01 9:57 ` Jonathan Miles
2009-12-01 13:21 ` Jonathan Miles [this message]
2009-12-01 16:08 ` Christoph Lameter
2009-12-01 18:07 ` Jonathan Miles
2009-12-01 18:42 ` Christoph Lameter
2009-12-04 20:36 ` OOM kernel behaviour - 2.6.32 Jonathan Miles
2009-12-09 13:52 ` Jonathan Miles
2009-12-01 15:35 ` OOM kernel behaviour David John
2009-12-01 16:07 ` Christoph Lameter
2009-12-01 17:10 ` David John
2009-12-01 17:26 ` Christoph Lameter
2009-12-02 15:55 ` Mel Gorman
2009-12-07 5:34 ` David John
2009-12-07 14:59 ` Mel Gorman
2009-12-08 3:41 ` David John
2009-12-01 17:32 ` Christoph Lameter
2009-12-02 3:17 ` David John
2009-12-02 4:29 ` KOSAKI Motohiro
2009-12-02 5:24 ` David John
2009-12-02 5:31 ` KOSAKI Motohiro
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=4B151862.9020201@cybus.co.uk \
--to=jon@cybus.co.uk \
--cc=cl@linux-foundation.org \
--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