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

  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 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.