From: Chris Mason <chris.mason@oracle.com>
To: James Bottomley <james.bottomley@hansenpartnership.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [BUG] fatal hang untarring 90GB file, possibly writeback related.
Date: Wed, 27 Apr 2011 13:34:03 -0400 [thread overview]
Message-ID: <1303925374-sup-7968@think> (raw)
In-Reply-To: <1303924902.2583.13.camel@mulgrave.site>
[ cc'd linux-ext4 ]
James is hitting softlockups in kswapd while doing writes to a large
ext4 file.
Excerpts from James Bottomley's message of 2011-04-27 13:21:42 -0400:
> On Wed, 2011-04-27 at 12:54 -0400, Chris Mason wrote:
> > Ok, I'd try turning it on so we catch the sleeping with a spinlock held
> > case better.
>
> Will do, that's CONFIG_PREEMPT (rather than CONFIG_PREEMPT_VOLUNTARY)?
>
> This is the trace with sysrq-l and sysrq-w
>
> The repro this time doesn't have a soft lockup, just the tar is hung and
> one of my CPUs is in 99% system.
> [ 454.742935] flush-253:2 D 0000000000000000 0 793 2 0x00000000
> [ 454.745425] ffff88006355b710 0000000000000046 ffff88006355b6b0 ffffffff00000000
> [ 454.747955] ffff880037ee9700 ffff88006355bfd8 ffff88006355bfd8 0000000000013b40
> [ 454.750506] ffffffff81a0b020 ffff880037ee9700 ffff88006355b710 000000018106e7c3
> [ 454.753048] Call Trace:
> [ 454.755537] [<ffffffff811c82b8>] do_get_write_access+0x1c6/0x38d
> [ 454.758071] [<ffffffff8106e88b>] ? autoremove_wake_function+0x3d/0x3d
> [ 454.760644] [<ffffffff811c8588>] jbd2_journal_get_write_access+0x2b/0x42
> [ 454.763206] [<ffffffff8118ea4f>] ? ext4_read_block_bitmap+0x54/0x2d0
> [ 454.765770] [<ffffffff811b5888>] __ext4_journal_get_write_access+0x58/0x66
> [ 454.768353] [<ffffffff811b8dbe>] ext4_mb_mark_diskspace_used+0x70/0x2ae
> [ 454.770942] [<ffffffff811bb10e>] ext4_mb_new_blocks+0x1c8/0x3c2
> [ 454.773501] [<ffffffff811b4628>] ext4_ext_map_blocks+0x1961/0x1c04
> [ 454.776082] [<ffffffff8122ed78>] ? radix_tree_gang_lookup_tag_slot+0x81/0xa2
> [ 454.778711] [<ffffffff810d55f9>] ? find_get_pages_tag+0x3b/0xd6
> [ 454.781323] [<ffffffff811967fa>] ext4_map_blocks+0x112/0x1e7
> [ 454.783894] [<ffffffff811984e8>] mpage_da_map_and_submit+0x93/0x2cd
> [ 454.786491] [<ffffffff81198de5>] ext4_da_writepages+0x2c1/0x44d
> [ 454.789090] [<ffffffff810ddeb4>] do_writepages+0x21/0x2a
So our flusher threads are stuck waiting in
jbd2_journal_get_write_access, which means they aren't cleaning dirty
pages.
In order to get write access, they probably need the transaction to
commit:
> [ 454.828711] jbd2/dm-2-8 D 0000000000000000 0 799 2 0x00000000
> [ 454.831390] ffff88006d59db10 0000000000000046 ffff88006d59daa0 ffffffff00000000
> [ 454.834094] ffff88006deb4500 ffff88006d59dfd8 ffff88006d59dfd8 0000000000013b40
> [ 454.836788] ffffffff81a0b020 ffff88006deb4500 ffff88006d59dad0 000000016d59dad0
> [ 454.839453] Call Trace:
> [ 454.842098] [<ffffffff810d5904>] ? lock_page+0x3e/0x3e
> [ 454.844738] [<ffffffff810d5904>] ? lock_page+0x3e/0x3e
> [ 454.847303] [<ffffffff8147a7c9>] io_schedule+0x63/0x7e
> [ 454.849877] [<ffffffff810d5912>] sleep_on_page+0xe/0x12
> [ 454.852469] [<ffffffff8147aea9>] __wait_on_bit+0x48/0x7b
> [ 454.855021] [<ffffffff810d5a8c>] wait_on_page_bit+0x72/0x74
> [ 454.857583] [<ffffffff8106e88b>] ? autoremove_wake_function+0x3d/0x3d
> [ 454.860171] [<ffffffff810d5b6b>] filemap_fdatawait_range+0x84/0x163
> [ 454.862744] [<ffffffff810d5c6e>] filemap_fdatawait+0x24/0x26
> [ 454.865299] [<ffffffff811c94a2>] jbd2_journal_commit_transaction+0x922/0x1194
But that seems to be waiting for a page lock. Probably the same page
lock held by the flusher thread? Looks like tar is stuck in the same
boat down below.
> [ 454.867892] [<ffffffff81008714>] ? __switch_to+0xc6/0x220
> [ 454.870496] [<ffffffff811cd3b6>] kjournald2+0xc9/0x20a
> [ 454.873103] [<ffffffff8106e84e>] ? remove_wait_queue+0x3a/0x3a
> [ 454.875690] [<ffffffff811cd2ed>] ? commit_timeout+0x10/0x10
> [ 454.878327] [<ffffffff8106e157>] kthread+0x84/0x8c
> [ 454.880961] [<ffffffff81483764>] kernel_thread_helper+0x4/0x10
> [ 454.883604] [<ffffffff8106e0d3>] ? kthread_worker_fn+0x148/0x148
> [ 454.886262] [<ffffffff81483760>] ? gs_change+0x13/0x13
> [ 454.888875] tar D ffff88006e573af8 0 991 838 0x00000000
> [ 454.891546] ffff880037f5b8a8 0000000000000086 ffff8801002a1d40 0000000000000282
> [ 454.894213] ffff88006d644500 ffff880037f5bfd8 ffff880037f5bfd8 0000000000013b40
> [ 454.896889] ffff8801002b4500 ffff88006d644500 ffff880037f5b8a8 ffffffff8106e7c3
> [ 454.899530] Call Trace:
> [ 454.902118] [<ffffffff8106e7c3>] ? prepare_to_wait+0x6c/0x78
> [ 454.904724] [<ffffffff811c82b8>] do_get_write_access+0x1c6/0x38d
> [ 454.907344] [<ffffffff8106e88b>] ? autoremove_wake_function+0x3d/0x3d
> [ 454.909967] [<ffffffff811991cc>] ? ext4_dirty_inode+0x33/0x4c
> [ 454.912574] [<ffffffff811c8588>] jbd2_journal_get_write_access+0x2b/0x42
> [ 454.915192] [<ffffffff811b5888>] __ext4_journal_get_write_access+0x58/0x66
> [ 454.917819] [<ffffffff81195526>] ext4_reserve_inode_write+0x41/0x83
> [ 454.920459] [<ffffffff811955e4>] ext4_mark_inode_dirty+0x7c/0x1f0
> [ 454.923070] [<ffffffff811991cc>] ext4_dirty_inode+0x33/0x4c
> [ 454.925660] [<ffffffff8113c3d6>] __mark_inode_dirty+0x2f/0x175
> [ 454.928247] [<ffffffff81143a0d>] generic_write_end+0x6c/0x7e
> [ 454.930865] [<ffffffff811983f6>] ext4_da_write_end+0x1a5/0x204
> [ 454.933454] [<ffffffff810d5e9d>] generic_file_buffered_write+0x17e/0x23a
> [ 454.936062] [<ffffffff810d6c9d>] __generic_file_aio_write+0x242/0x272
> [ 454.938648] [<ffffffff810d6d2e>] generic_file_aio_write+0x61/0xba
> [ 454.941288] [<ffffffff8118fe00>] ext4_file_write+0x1dc/0x234
> [ 454.943909] [<ffffffff8111edab>] do_sync_write+0xbf/0xff
> [ 454.946501] [<ffffffff8114b9fc>] ? fsnotify+0x1eb/0x217
> [ 454.949114] [<ffffffff811f1866>] ? selinux_file_permission+0x58/0xb4
> [ 454.951736] [<ffffffff811e9cfe>] ? security_file_permission+0x2e/0x33
> [ 454.954349] [<ffffffff8111f196>] ? rw_verify_area+0xb0/0xcd
> [ 454.956943] [<ffffffff8111f421>] vfs_write+0xac/0xf3
> [ 454.959530] [<ffffffff8111f610>] sys_write+0x4a/0x6e
> [ 454.962129] [<ffffffff81482642>] system_call_fastpath+0x16/0x1b
-chris
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-04-27 17:34 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-27 16:09 [BUG] fatal hang untarring 90GB file, possibly writeback related James Bottomley
2011-04-27 16:33 ` Chris Mason
2011-04-27 16:50 ` James Bottomley
2011-04-27 16:54 ` Chris Mason
2011-04-27 17:21 ` James Bottomley
2011-04-27 17:34 ` Chris Mason [this message]
2011-04-27 17:50 ` James Bottomley
2011-04-27 18:25 ` Colin Ian King
2011-04-28 15:57 ` James Bottomley
2011-04-27 20:05 ` James Bottomley
2011-04-28 11:36 ` Colin Ian King
2011-04-28 12:29 ` Chris Mason
2011-04-28 13:42 ` Colin Ian King
2011-04-28 13:45 ` Chris Mason
2011-04-28 14:01 ` Colin Ian King
2011-04-28 14:04 ` Chris Mason
2011-04-28 15:23 ` Colin Ian King
2011-04-28 14:25 ` Jan Kara
2011-04-28 14:33 ` Jan Kara
2011-04-28 14:58 ` Colin Ian King
2011-04-28 22:40 ` Jan Kara
2011-04-28 22:44 ` James Bottomley
2011-05-03 18:55 ` Colin Ian King
2011-04-28 16:11 ` James Bottomley
2011-04-28 14:49 ` James Bottomley
2011-04-28 13:52 ` Jan Kara
2011-04-28 14:07 ` Mel Gorman
2011-04-28 14:25 ` James Bottomley
2011-04-28 15:08 ` Mel Gorman
2011-04-28 16:01 ` James Bottomley
2011-04-28 16:50 ` James Bottomley
2011-04-28 16:56 ` James Bottomley
2011-04-28 17:18 ` Mel Gorman
2011-04-28 18:30 ` James Bottomley
2011-04-28 19:21 ` Mel Gorman
2011-04-28 19:59 ` James Bottomley
2011-04-28 20:27 ` Mel Gorman
2011-04-29 15:02 ` James Bottomley
2011-04-28 21:12 ` James Bottomley
2011-04-28 22:43 ` James Bottomley
2011-05-03 9:13 ` Mel Gorman
2011-05-03 14:13 ` James Bottomley
2011-05-03 14:22 ` James Bottomley
2011-05-06 7:42 ` Mel Gorman
2011-05-06 8:07 ` Mel Gorman
2011-05-09 18:16 ` James Bottomley
2011-05-10 10:21 ` Mel Gorman
2011-05-10 10:33 ` Pekka Enberg
2011-05-10 14:01 ` James Bottomley
2011-05-10 14:35 ` Mel Gorman
2011-05-10 15:29 ` James Bottomley
2011-05-10 15:57 ` James Bottomley
2011-05-10 17:05 ` James Bottomley
2011-05-10 17:17 ` Mel Gorman
2011-05-10 17:29 ` James Bottomley
2011-05-10 21:08 ` Raghavendra D Prabhu
2011-05-11 9:16 ` Mel Gorman
2011-05-06 11:42 ` Mel Gorman
2011-05-06 15:44 ` Mel Gorman
2011-05-06 19:14 ` James Bottomley
2011-05-06 19:37 ` Mel Gorman
2011-05-10 5:37 ` Colin Ian King
2011-05-06 15:58 ` James Bottomley
2011-05-03 9:54 ` Colin Ian King
2011-04-28 17:10 ` Colin Ian King
2011-04-28 0:37 ` Dave Chinner
2011-04-29 10:23 ` Sedat Dilek
2011-04-29 15:37 ` James Bottomley
2011-04-29 16:31 ` James Bottomley
2011-04-29 18:02 ` James Bottomley
2011-05-02 20:04 ` James Bottomley
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=1303925374-sup-7968@think \
--to=chris.mason@oracle.com \
--cc=james.bottomley@hansenpartnership.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).