From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <clameter@sgi.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Christoph Hellwig <hch@lst.de>, Mel Gorman <mel@skynet.ie>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
David Chinner <dgc@sgi.com>, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK
Date: Sat, 29 Sep 2007 11:14:02 +0200 [thread overview]
Message-ID: <1191057242.18147.110.camel@lappy> (raw)
In-Reply-To: <20070929020141.e7684eb8.akpm@linux-foundation.org>
On Sat, 2007-09-29 at 02:01 -0700, Andrew Morton wrote:
> On Sat, 29 Sep 2007 10:53:41 +0200 Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> >
> > On Sat, 2007-09-29 at 10:47 +0200, Peter Zijlstra wrote:
> >
> > > Ah, right, that was the detail... all this lumpy reclaim is useless for
> > > atomic allocations. And with SLUB using higher order pages, atomic !0
> > > order allocations will be very very common.
> > >
> > > One I can remember was:
> > >
> > > add_to_page_cache()
> > > radix_tree_insert()
> > > radix_tree_node_alloc()
> > > kmem_cache_alloc()
> > >
> > > which is an atomic callsite.
> > >
> > > Which leaves us in a situation where we can load pages, because there is
> > > free memory, but can't manage to allocate memory to track them..
> >
> > Ah, I found a boot log of one of these sessions, its also full of
> > order-2 OOMs.. :-/
>
> oom-killings, or page allocation failures? The latter, one hopes.
Linux version 2.6.23-rc4-mm1-dirty (root@dyad) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #27 Tue Sep 18 15:40:35 CEST 2007
...
mm_tester invoked oom-killer: gfp_mask=0x40d0, order=2, oomkilladj=0
Call Trace:
611b3878: [<6002dd28>] printk_ratelimit+0x15/0x17
611b3888: [<60052ed4>] out_of_memory+0x80/0x100
611b38c8: [<60054b0c>] __alloc_pages+0x1ed/0x280
611b3948: [<6006c608>] allocate_slab+0x5b/0xb0
611b3968: [<6006c705>] new_slab+0x7e/0x183
611b39a8: [<6006cbae>] __slab_alloc+0xc9/0x14b
611b39b0: [<6011f89f>] radix_tree_preload+0x70/0xbf
611b39b8: [<600980f2>] do_mpage_readpage+0x3b3/0x472
611b39e0: [<6011f89f>] radix_tree_preload+0x70/0xbf
611b39f8: [<6006cc81>] kmem_cache_alloc+0x51/0x98
611b3a38: [<6011f89f>] radix_tree_preload+0x70/0xbf
611b3a58: [<6004f8e2>] add_to_page_cache+0x22/0xf7
611b3a98: [<6004f9c6>] add_to_page_cache_lru+0xf/0x24
611b3ab8: [<6009821e>] mpage_readpages+0x6d/0x109
611b3ac0: [<600d59f0>] ext3_get_block+0x0/0xf2
611b3b08: [<6005483d>] get_page_from_freelist+0x8d/0xc1
611b3b88: [<600d6937>] ext3_readpages+0x18/0x1a
611b3b98: [<60056f00>] read_pages+0x37/0x9b
611b3bd8: [<60057064>] __do_page_cache_readahead+0x100/0x157
611b3c48: [<60057196>] do_page_cache_readahead+0x52/0x5f
611b3c78: [<60050ab4>] filemap_fault+0x145/0x278
611b3ca8: [<60022b61>] run_syscall_stub+0xd1/0xdd
611b3ce8: [<6005eae3>] __do_fault+0x7e/0x3ca
611b3d68: [<6005ee60>] do_linear_fault+0x31/0x33
611b3d88: [<6005f149>] handle_mm_fault+0x14e/0x246
611b3da8: [<60120a7b>] __up_read+0x73/0x7b
611b3de8: [<60013177>] handle_page_fault+0x11f/0x23b
611b3e48: [<60013419>] segv+0xac/0x297
611b3f28: [<60013367>] segv_handler+0x68/0x6e
611b3f48: [<600232ad>] get_skas_faultinfo+0x9c/0xa1
611b3f68: [<60023853>] userspace+0x13a/0x19d
611b3fc8: [<60010d58>] fork_handler+0x86/0x8d
Mem-info:
Normal per-cpu:
CPU 0: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0
Active:11 inactive:9 dirty:0 writeback:1 unstable:0
free:19533 slab:10587 mapped:0 pagetables:260 bounce:0
Normal free:78132kB min:4096kB low:5120kB high:6144kB active:44kB inactive:36kB present:129280kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 7503*4kB 5977*8kB 19*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 78132kB
Swap cache: add 1192822, delete 1192790, find 491441/626861, race 0+1
Free swap = 455300kB
Total swap = 524280kB
Free swap: 455300kB
32768 pages of RAM
0 pages of HIGHMEM
1948 reserved pages
11 pages shared
32 pages swap cached
Out of memory: kill process 2647 (portmap) score 2233 or a child
Killed process 2647 (portmap)
next prev parent reply other threads:[~2007-09-29 9:18 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-19 3:36 [00/17] [RFC] Virtual Compound Page Support Christoph Lameter
2007-09-19 3:36 ` [01/17] Vmalloc: Move vmalloc_to_page to mm/vmalloc Christoph Lameter
2007-09-19 3:36 ` [02/17] Vmalloc: add const Christoph Lameter
2007-09-19 3:36 ` [03/17] is_vmalloc_addr(): Check if an address is within the vmalloc boundaries Christoph Lameter
2007-09-19 6:32 ` David Rientjes
2007-09-19 7:24 ` Anton Altaparmakov
2007-09-19 8:09 ` David Rientjes
2007-09-19 8:44 ` Anton Altaparmakov
2007-09-19 9:19 ` David Rientjes
2007-09-19 13:23 ` Anton Altaparmakov
2007-09-19 17:29 ` Christoph Lameter
2007-09-19 17:52 ` Anton Altaparmakov
2007-09-19 17:29 ` Christoph Lameter
2007-09-19 17:52 ` Anton Altaparmakov
2007-09-19 3:36 ` [04/17] vmalloc: clean up page array indexing Christoph Lameter
2007-09-19 3:36 ` [05/17] vunmap: return page array Christoph Lameter
2007-09-19 8:05 ` KAMEZAWA Hiroyuki
2007-09-19 22:15 ` Christoph Lameter
2007-09-20 0:47 ` KAMEZAWA Hiroyuki
2007-09-19 3:36 ` [06/17] vmalloc_address(): Determine vmalloc address from page struct Christoph Lameter
2007-09-19 3:36 ` [07/17] GFP_VFALLBACK: Allow fallback of compound pages to virtual mappings Christoph Lameter
2007-09-19 3:36 ` [08/17] Pass vmalloc address in page->private Christoph Lameter
2007-09-19 3:36 ` [09/17] VFALLBACK: Debugging aid Christoph Lameter
2007-09-19 3:36 ` [10/17] Use GFP_VFALLBACK for sparsemem Christoph Lameter
2007-09-19 3:36 ` [11/17] GFP_VFALLBACK for zone wait table Christoph Lameter
2007-09-19 3:36 ` [12/17] Virtual Compound page allocation from interrupt context Christoph Lameter
2007-09-19 3:36 ` [13/17] Virtual compound page freeing in " Christoph Lameter
2007-09-18 20:36 ` Nick Piggin
2007-09-20 17:50 ` Christoph Lameter
2007-09-19 3:36 ` [14/17] Allow bit_waitqueue to wait on a bit in a vmalloc area Christoph Lameter
2007-09-19 4:12 ` Gabriel C
2007-09-19 17:40 ` Christoph Lameter
2007-09-19 3:36 ` [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK Christoph Lameter
2007-09-27 21:42 ` Nick Piggin
2007-09-28 17:33 ` Christoph Lameter
2007-09-28 5:14 ` Nick Piggin
2007-10-01 20:50 ` Christoph Lameter
2007-10-02 8:43 ` Nick Piggin
2007-10-04 16:16 ` SLUB performance regression vs SLAB Matthew Wilcox
2007-10-04 17:38 ` Christoph Lameter
2007-10-04 17:50 ` Arjan van de Ven
2007-10-04 17:58 ` Christoph Lameter
2007-10-04 18:26 ` Peter Zijlstra
2007-10-04 20:48 ` David Miller
2007-10-04 20:58 ` Matthew Wilcox
2007-10-04 21:05 ` David Miller
2007-10-04 21:11 ` Christoph Lameter
2007-10-04 23:39 ` David Schwartz
2007-10-04 23:49 ` Chuck Ebbert
2007-10-05 4:18 ` David Schwartz
2007-10-04 18:32 ` Matthew Wilcox
2007-10-04 17:49 ` Christoph Lameter
2007-10-04 19:28 ` Matthew Wilcox
2007-10-04 19:05 ` Christoph Lameter
2007-10-04 19:46 ` Siddha, Suresh B
2007-10-04 20:55 ` David Miller
2007-10-04 21:02 ` Chuck Ebbert
2007-10-04 21:11 ` David Miller
2007-10-04 21:47 ` Chuck Ebbert
2007-10-04 22:07 ` David Miller
2007-10-04 22:23 ` David Chinner
2007-10-05 6:48 ` Jens Axboe
2007-10-05 9:19 ` Pekka Enberg
2007-10-05 9:28 ` Jens Axboe
2007-10-05 11:12 ` Andi Kleen
2007-10-05 12:39 ` Jens Axboe
2007-10-05 19:31 ` Christoph Lameter
2007-10-05 19:32 ` Christoph Lameter
2007-10-05 11:56 ` Matthew Wilcox
2007-10-05 12:37 ` Jens Axboe
2007-10-05 19:27 ` Christoph Lameter
2007-10-05 20:32 ` Peter Zijlstra
2007-10-05 21:31 ` David Miller
2007-10-04 21:05 ` Matthew Wilcox
2007-10-05 2:43 ` Christoph Lameter
2007-10-05 2:53 ` Arjan van de Ven
2007-09-28 17:55 ` [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK Peter Zijlstra
2007-09-28 18:20 ` Christoph Lameter
2007-09-28 18:25 ` Peter Zijlstra
2007-09-28 18:41 ` Christoph Lameter
2007-09-28 20:22 ` Nick Piggin
2007-09-28 21:14 ` Mel Gorman
2007-09-28 20:59 ` Mel Gorman
2007-09-29 8:13 ` Andrew Morton
2007-09-29 8:47 ` Peter Zijlstra
2007-09-29 8:53 ` Peter Zijlstra
2007-09-29 9:01 ` Andrew Morton
2007-09-29 9:14 ` Peter Zijlstra [this message]
2007-09-29 9:27 ` Andrew Morton
2007-09-28 20:19 ` Nick Piggin
2007-09-29 19:20 ` Andrew Morton
2007-09-29 19:09 ` Nick Piggin
2007-09-30 20:12 ` Andrew Morton
2007-09-30 4:16 ` Nick Piggin
2007-09-29 9:00 ` Andrew Morton
2007-10-01 20:55 ` Christoph Lameter
2007-10-01 21:30 ` Andrew Morton
2007-10-01 21:38 ` Christoph Lameter
2007-10-01 21:45 ` Andrew Morton
2007-10-01 21:52 ` Christoph Lameter
2007-10-02 9:19 ` Peter Zijlstra
2007-09-29 8:45 ` Peter Zijlstra
2007-10-01 21:01 ` Christoph Lameter
2007-10-02 8:37 ` Nick Piggin
2007-09-28 21:05 ` Mel Gorman
2007-10-01 21:10 ` Christoph Lameter
2007-09-19 3:36 ` [16/17] Allow virtual fallback for buffer_heads Christoph Lameter
2007-09-19 3:36 ` [17/17] Allow virtual fallback for dentries Christoph Lameter
2007-09-19 7:34 ` [00/17] [RFC] Virtual Compound Page Support Anton Altaparmakov
2007-09-19 8:34 ` Eric Dumazet
2007-09-19 17:33 ` Christoph Lameter
2007-09-19 8:24 ` Andi Kleen
2007-09-19 17:36 ` Christoph Lameter
2007-09-25 23:42 [00/17] Virtual Compound Page Support V1 Christoph Lameter
2007-09-25 23:42 ` [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK Christoph Lameter
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=1191057242.18147.110.camel@lappy \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=dgc@sgi.com \
--cc=hch@lst.de \
--cc=jens.axboe@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@skynet.ie \
--cc=nickpiggin@yahoo.com.au \
/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
Powered by JetHome