From: Antoine Martin <antoine@devloop.org.uk>
To: Avi Kivity <avi@redhat.com>
Cc: Antoine Martin <antoine@nagafix.co.uk>,
Mark McLoughlin <markmc@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>,
davem@davemloft.net
Subject: Re: virtio net regression
Date: Tue, 19 May 2009 17:16:02 +0700 [thread overview]
Message-ID: <4A1286E2.4070805@devloop.org.uk> (raw)
In-Reply-To: <4A112CCC.1040903@redhat.com>
Avi Kivity wrote:
> Antoine Martin wrote:
>> Hi,
>>
>> Here is another one, any ideas?
>> These oopses do look quite deep. Is it normal to end up in tcp_send_ack
>> from pdflush??
>>
>>
>
> I think it can happen anywhere, part of the net softirq.
Hah, gotcha.
>
>> Cheers
>> Antoine
>>
>> [929492.154634] pdflush: page allocation failure. order:0, mode:0x20
>>
>
> You're out of memory.
That's quite odd, the guest wasn't even hitting the swap at the tine.
> How much memory did you allocate to the guest? did you balloon it?
512MB, no ballooning.
>
>> [929492.154637] Pid: 291, comm: pdflush Not tainted 2.6.29.2 #5
>> [929492.154639] Call Trace:
>> [929492.154641] <IRQ> [<ffffffff8027e8bc>]
>> __alloc_pages_internal+0x3e1/0x401
>> [929492.154649] [<ffffffff8055b5ea>] try_fill_recv+0xa1/0x182
>> [929492.154652] [<ffffffff8055c1fc>] virtnet_poll+0x533/0x5ab
>> [929492.154655] [<ffffffff80632bba>] net_rx_action+0x70/0x143
>> [929492.154658] [<ffffffff8023f18c>] __do_softirq+0x83/0x123
>> [929492.154661] [<ffffffff8020d35c>] call_softirq+0x1c/0x28
>> [929492.154664] [<ffffffff8020e2c0>] do_softirq+0x3c/0x85
>> [929492.154666] [<ffffffff8023eea3>] irq_exit+0x3f/0x7a
>> [929492.154668] [<ffffffff8020e59c>] do_IRQ+0x12b/0x14f
>> [929492.154670] [<ffffffff8020cad3>] ret_from_intr+0x0/0x29
>> [929492.154672] <EOI> [<ffffffff802c22b1>]
>> __set_page_dirty_buffers+0x0/0x8f
>> [929492.154677] [<ffffffff8031702b>] bget_one+0x0/0xb
>> [929492.154680] [<ffffffff80316fa2>] walk_page_buffers+0x2/0x8b
>> [929492.154682] [<ffffffff803185bc>] ext3_ordered_writepage+0xae/0x134
>> [929492.154685] [<ffffffff8027ea46>] __writepage+0xa/0x25
>> [929492.154687] [<ffffffff8027f19f>] write_cache_pages+0x206/0x322
>> [929492.154689] [<ffffffff8027ea3c>] __writepage+0x0/0x25
>> [929492.154691] [<ffffffff8027f2fe>] do_writepages+0x27/0x2d
>> [929492.154694] [<ffffffff802bd3f6>]
>> __writeback_single_inode+0x1a7/0x3b5
>> [929492.154696] [<ffffffff8020a68c>] __switch_to+0xb4/0x38c
>> [929492.154698] [<ffffffff802bda76>] generic_sync_sb_inodes+0x2a7/0x458
>> [929492.154701] [<ffffffff802bde00>] writeback_inodes+0x8d/0xe6
>> [929492.154704] [<ffffffff807296e2>] _spin_lock+0x5/0x7
>> [929492.155056] [<ffffffff8027f432>] wb_kupdate+0x9f/0x116
>> [929492.155058] [<ffffffff80280095>] pdflush+0x14b/0x202
>> [929492.155061] [<ffffffff8027f393>] wb_kupdate+0x0/0x116
>> [929492.155063] [<ffffffff8027ff4a>] pdflush+0x0/0x202
>> [929492.155065] [<ffffffff8027ff4a>] pdflush+0x0/0x202
>> [929492.155068] [<ffffffff8024c127>] kthread+0x47/0x73
>> [929492.155070] [<ffffffff8020d25a>] child_rip+0xa/0x20
>> [929492.155072] [<ffffffff8024c0e0>] kthread+0x0/0x73
>> [929492.183142] [<ffffffff8020d250>] child_rip+0x0/0x20
>> [929492.183145] Mem-Info:
>> [929492.183147] DMA per-cpu:
>> [929492.183149] CPU 0: hi: 0, btch: 1 usd: 0
>> [929492.183151] DMA32 per-cpu:
>> [929492.183154] CPU 0: hi: 186, btch: 31 usd: 184
>> [929492.183158] Active_anon:2755 active_file:39849 inactive_anon:2972
>> [929492.183159] inactive_file:70353 unevictable:0 dirty:4172
>> writeback:1580 unstable:0
>> [929492.183161] free:734 slab:5619 mapped:15047 pagetables:927 bounce:0
>> [929492.183166] DMA free:1968kB min:28kB low:32kB high:40kB
>> active_anon:0kB inactive_anon:40kB active_file:2116kB
>> inactive_file:1880kB unevictable:0kB present:5448kB pages_scanned:0
>> all_unreclaimable? no
>> [929492.183169] lowmem_reserve[]: 0 489 489 489
>> [929492.183176] DMA32 free:968kB min:2812kB low:3512kB high:4216kB
>> active_anon:11020kB inactive_anon:11848kB active_file:157280kB
>> inactive_file:279532kB unevictable:0kB present:500896kB pages_scanned:0
>> all_unreclaimable? no
>> [929492.183180] lowmem_reserve[]: 0 0 0 0
>> [929492.183183] DMA: 6*4kB 2*8kB 3*16kB 1*32kB 1*64kB 2*128kB 0*256kB
>> 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1976kB
>> [929492.183235] DMA32: 0*4kB 1*8kB 0*16kB 0*32kB 1*64kB 3*128kB 2*256kB
>> 0*512kB 0*1024kB 0*2048kB 0*4096kB = 968kB
>> [929492.183244] 110992 total pagecache pages
>> [929492.183246] 739 pages in swap cache
>> [929492.183248] Swap cache stats: add 8996, delete 8257, find
>> 92604/93191
>> [929492.183250] Free swap = 1040016kB
>> [929492.183252] Total swap = 1048568kB
>> [929492.186003] 131056 pages RAM
>> [929492.186006] 4799 pages reserved
>> [929492.186007] 44697 pages shared
>> [929492.186008] 90516 pages non-shared
>> [930274.380075] eth0: no IPv6 routers present
>>
>>
> Strange, seems to be a bit of free memory here.
There should be lots, all this host is doing is apache+sftp...
Assuming I can make it re-occur (stress testing it?), how would I dig
further to find the cause of this memory exhaustion? /proc/meminfo and
friends?
Cheers
Antoine
next prev parent reply other threads:[~2009-05-19 10:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-15 20:04 virtio net regression Antoine Martin
2009-04-15 23:38 ` Antoine Martin
2009-04-19 11:48 ` Avi Kivity
2009-04-20 11:12 ` Mark McLoughlin
2009-04-20 15:09 ` Antoine Martin
[not found] ` <49EC8F1D.7000109@nagafix.co.uk>
2009-04-28 18:57 ` Antoine Martin
2009-05-09 13:19 ` Antoine Martin
2009-05-13 12:58 ` Antoine Martin
2009-05-14 3:52 ` David Miller
2009-05-18 9:39 ` Avi Kivity
2009-05-19 10:16 ` Antoine Martin [this message]
2009-05-19 10:21 ` Avi Kivity
2009-05-19 10:47 ` Antoine Martin
2009-05-19 13:03 ` Avi Kivity
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=4A1286E2.4070805@devloop.org.uk \
--to=antoine@devloop.org.uk \
--cc=antoine@nagafix.co.uk \
--cc=avi@redhat.com \
--cc=davem@davemloft.net \
--cc=kvm@vger.kernel.org \
--cc=markmc@redhat.com \
--cc=rusty@rustcorp.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.