From: Lukas Hejtmanek <xhejtman@mail.muni.cz>
To: Andrew Morton <akpm@osdl.org>
Cc: zaphodb@zaphods.net, marcelo.tosatti@cyclades.com,
piggin@cyberone.com.au, linux-kernel@vger.kernel.org
Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures
Date: Thu, 2 Dec 2004 22:03:48 +0100 [thread overview]
Message-ID: <20041202210348.GD20771@mail.muni.cz> (raw)
In-Reply-To: <20041202122546.59ff814f.akpm@osdl.org>
On Thu, Dec 02, 2004 at 12:25:46PM -0800, Andrew Morton wrote:
> Lukas Hejtmanek <xhejtman@mail.muni.cz> wrote:
> >
> > I found out that 2.6.6-bk4 kernel is OK.
>
> That kernel didn't have the TSO thing. Pretty much all of these reports
> have been against e1000_alloc_rx_buffers() since the TSO changes went in.
>
> I may have been asleep at the time. Could someone pleeeeze explain to me
> why the introduction of TSO has thrown this additional pressure onto the
> atomic memory allocations?
>
> Did you try disabling TSO, btw?
I did it. Allocation failure is still there :(
ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: off
kernel: swapper: page allocation failure. order:0, mode:0x20
kernel: [__alloc_pages+441/862] __alloc_pages+0x1b9/0x363
kernel: [__get_free_pages+42/63] __get_free_pages+0x25/0x3f
kernel: [kmem_getpages+37/201] kmem_getpages+0x21/0xc9
kernel: [cache_grow+175/333] cache_grow+0xab/0x14d
kernel: [cache_alloc_refill+376/537] cache_alloc_refill+0x174/0x219
kernel: [kmem_ptr_validate+2/73] kmem_cache_alloc+0x4b/0x4d
kernel: [alloc_skb+41/224] alloc_skb+0x25/0xe0
kernel: [e1000_alloc_rx_buffers+72/227] e1000_alloc_rx_buffers+0x44/0xe3
kernel: [e1000_clean_rx_irq+402/1095] e1000_clean_rx_irq+0x18e/0x447
kernel: [__kfree_skb+135/253] __kfree_skb+0x83/0xfd
kernel: [e1000_clean+85/202] e1000_clean+0x51/0xca
This is failure really related to e1000. But there is another one:
kernel: swapper: page allocation failure. order:0, mode:0x20
kernel: [__alloc_pages+441/862] __alloc_pages+0x1b9/0x363
kernel: [__get_free_pages+42/63] __get_free_pages+0x25/0x3f
kernel: [kmem_getpages+37/201] kmem_getpages+0x21/0xc9
kernel: [cache_grow+175/333] cache_grow+0xab/0x14d
kernel: [cache_alloc_refill+376/537] cache_alloc_refill+0x174/0x219
kernel: [kmem_ptr_validate+2/73] kmem_cache_alloc+0x4b/0x4d
kernel: [alloc_skb+41/224] alloc_skb+0x25/0xe0
kernel: [tcp_send_ack+57/223] tcp_send_ack+0x35/0xdf
kernel: [tcp_delack_timer+247/447] tcp_delack_timer+0xf3/0x1bf
kernel: [i8042_controller_init+0/315] i8042_timer_func+0x1f/0x23
kernel: [tcp_delack_timer+4/447] tcp_delack_timer+0x0/0x1bf
kernel: [run_timer_softirq+207/392] run_timer_softirq+0xcf/0x188
kernel: [net_rx_action+123/246] net_rx_action+0x77/0xf6
kernel: [__do_softirq+183/198] __do_softirq+0xb7/0xc6
kernel: [do_softirq+45/47] do_softirq+0x2d/0x2f
kernel: [do_IRQ+274/304] do_IRQ+0x112/0x130
I still suspect XFS and it's page buffer as order 0 allocation shoud be
successful when:
kernel: Free pages: 500kB (140kB HighMem)
kernel: Active:22289 inactive:223140 dirty:102306 writeback:2663 unstable:0 free:125 slab:11088 mapped:18036 pagetables:428
kernel: DMA free:8kB min:16kB low:32kB high:48kB active:1132kB inactive:9912kB present:16384kB
kernel: protections[]: 0 0 0
kernel: Normal free:352kB min:936kB low:1872kB high:2808kB active:53460kB inactive:788652kB present:901120kB
kernel: protections[]: 0 0 0
kernel: HighMem free:140kB min:128kB low:256kB high:384kB active:34564kB inactive:93996kB present:131008kB
kernel: protections[]: 0 0 0
kernel: DMA: 0*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 8kB
kernel: Normal: 0*4kB 0*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 352kB
kernel: HighMem: 1*4kB 1*8kB 2*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 140kB
I can see in each zone at least one page free.
min_free_kbytes is set to 957
--
Lukáš Hejtmánek
next prev parent reply other threads:[~2004-12-02 21:08 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-03 22:24 Kernel 2.6.9 Multiple Page Allocation Failures (Part 2) Stefan Schmidt
2004-11-04 12:17 ` Marcelo Tosatti
2004-11-04 18:18 ` Stefan Schmidt
2004-11-09 16:41 ` Kernel 2.6.9 Multiple Page Allocation Failures Marcelo Tosatti
2004-11-09 22:35 ` Lukas Hejtmanek
2004-11-09 22:46 ` Andrew Morton
2004-11-09 22:44 ` Lukas Hejtmanek
2004-11-09 20:33 ` Marcelo Tosatti
2004-11-10 20:35 ` Lukas Hejtmanek
2004-11-10 21:09 ` Andrew Morton
2004-11-10 21:24 ` Lukas Hejtmanek
2004-11-10 21:47 ` Andrew Morton
2004-11-10 21:28 ` Lukas Hejtmanek
2004-11-10 18:11 ` Marcelo Tosatti
2004-11-11 1:04 ` Lukas Hejtmanek
2004-11-11 21:44 ` Lukas Hejtmanek
2004-11-12 12:09 ` Nick Piggin
2004-11-13 14:47 ` Stefan Schmidt
2004-11-16 9:33 ` Marcelo Tosatti
2004-11-16 17:05 ` Lukas Hejtmanek
2004-11-21 1:43 ` Stefan Schmidt
2004-11-21 2:42 ` Stefan Schmidt
2004-12-02 19:54 ` Lukas Hejtmanek
2004-12-02 20:25 ` Andrew Morton
2004-12-02 21:03 ` Lukas Hejtmanek [this message]
2004-12-02 22:31 ` Stefan Schmidt
2004-12-02 22:48 ` Lukas Hejtmanek
2004-12-02 22:56 ` Andrew Morton
2004-12-02 23:18 ` Lukas Hejtmanek
2004-12-03 0:18 ` Andrew Morton
2004-12-03 12:11 ` Lukas Hejtmanek
2004-12-03 12:17 ` Lukas Hejtmanek
2004-12-07 22:52 ` Nick Piggin
2004-12-07 22:59 ` Lukas Hejtmanek
2004-12-07 23:05 ` Nick Piggin
2004-12-08 11:18 ` Lukas Hejtmanek
2004-12-08 11:23 ` Nick Piggin
2004-12-08 11:46 ` Lukas Hejtmanek
2004-12-08 13:14 ` Lukas Hejtmanek
2004-12-09 8:52 ` Nick Piggin
2004-12-09 9:02 ` Lukas Hejtmanek
2004-12-09 10:29 ` Nick Piggin
2004-12-09 10:37 ` Lukas Hejtmanek
2004-12-03 6:18 ` Nathan Scott
2004-12-03 7:06 ` Andrew Morton
2004-12-07 11:17 ` Lukas Hejtmanek
2004-12-08 0:15 ` Nathan Scott
2004-12-08 0:36 ` Lukas Hejtmanek
2004-12-03 10:35 ` Christoph Hellwig
2004-12-03 10:58 ` P
2004-12-03 17:11 ` Andrew Morton
2004-11-09 23:52 ` Stefan Schmidt
2004-11-10 1:27 ` 2.6.10-rc1-mm4 -1 EAGAIN after allocation failure was: " Stefan Schmidt
2004-11-10 1:39 ` Andrew Morton
2004-11-10 2:03 ` Stefan Schmidt
2004-11-10 2:21 ` Andrew Morton
2004-11-10 4:24 ` Nick Piggin
2004-11-10 10:28 ` Stefan Schmidt
2004-11-10 12:06 ` Stefan Schmidt
2004-11-10 8:58 ` Marcelo Tosatti
2004-11-10 12:48 ` Stefan Schmidt
2004-11-10 10:56 ` Marcelo Tosatti
2004-11-11 1:23 ` Nick Piggin
2004-11-11 18:31 ` jhigdon
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=20041202210348.GD20771@mail.muni.cz \
--to=xhejtman@mail.muni.cz \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=piggin@cyberone.com.au \
--cc=zaphodb@zaphods.net \
/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