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
-- strict thread matches above, loose matches on Subject: below --
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 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.