From: Chris Mason <chris.mason@fusionio.com>
To: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Steven Rostedt <srostedt@redhat.com>,
"tytso@mit.edu" <tytso@mit.edu>, Jan Kara <jack@suse.cz>
Subject: compaction vs data=ordered on ext34
Date: Fri, 4 Jan 2013 08:23:05 -0500 [thread overview]
Message-ID: <20130104132305.GG14537@shiny> (raw)
Hi everyone,
Steve recently hit very long stalls in firefox, and was able to snag
this sysrq-w
[223349.032831] firefox-bin D 0000000000000000 0 5798 5797 0x00000004
[223349.033208] ffff8801abb69798 0000000000000086 ffff8801abb696d8 ffff8801abb69fd8
[223349.033622] 0000000000004000 ffff8801abb69fd8 ffffffff81813420 ffff880209d7e180
[223349.034053] 000000000000003c ffff88023f02cb00 ffff88023f01d080 ffff88023f02cac0
[223349.034472] Call Trace:
[223349.034609] [<ffffffff8145abbc>] ? cache_flusharray+0x8f/0xb9
[223349.034909] [<ffffffff81110b56>] ? free_pcppages_bulk+0x406/0x450
[223349.035228] [<ffffffff81191aa0>] ? __wait_on_buffer+0x30/0x30
[223349.035530] [<ffffffff8145f41f>] ? io_schedule+0x8f/0xd0
[223349.035812] [<ffffffff81191aae>] ? sleep_on_buffer+0xe/0x20
[223349.036103] [<ffffffff8145d72a>] ? __wait_on_bit_lock+0x5a/0xc0
[223349.036432] [<ffffffff8111201e>] ? free_hot_cold_page_list+0x5e/0x100
[223349.036769] [<ffffffff81191aa0>] ? __wait_on_buffer+0x30/0x30
[223349.037073] [<ffffffff8145d80c>] ? out_of_line_wait_on_bit_lock+0x7c/0x90
[223349.037427] [<ffffffff81067300>] ? autoremove_wake_function+0x40/0x40
[223349.037767] [<ffffffff81155c5e>] ? buffer_migrate_lock_buffers+0x7e/0xb0
[223349.038116] [<ffffffff81156761>] ? buffer_migrate_page+0x61/0x160
[223349.038437] [<ffffffff81156536>] ? move_to_new_page+0x96/0x260
[223349.038749] [<ffffffff81156c11>] ? migrate_pages+0x3b1/0x4b0
[223349.039047] [<ffffffff8112b7b0>] ? compact_checklock_irqsave.isra.14+0x100/0x100
[223349.039433] [<ffffffff8112c48f>] ? compact_zone+0x17f/0x430
[223349.039729] [<ffffffff8135c3eb>] ? __kmalloc_reserve+0x3b/0xa0
[223349.040036] [<ffffffff8112c9f7>] ? compact_zone_order+0x87/0xd0
[223349.040349] [<ffffffff8112cb11>] ? try_to_compact_pages+0xd1/0x100
[223349.040674] [<ffffffff8145a6e3>] ? __alloc_pages_direct_compact+0xc3/0x1fa
[223349.041034] [<ffffffff81111468>] ? __alloc_pages_nodemask+0x7b8/0xa00
[223349.041368] [<ffffffff8114d003>] ? alloc_pages_vma+0xb3/0x1d0
[223349.041673] [<ffffffff8115ab28>] ? do_huge_pmd_anonymous_page+0x138/0x300
[223349.042030] [<ffffffff814634e8>] ? do_page_fault+0x198/0x510
[223349.042331] [<ffffffff81125b36>] ? vm_mmap_pgoff+0x96/0xb0
[223349.042640] [<ffffffff8146095f>] ? page_fault+0x1f/0x30
This shows THP -> compaction -> buffer_migrate_page then waiting for a
buffer to unlock. He was doing backups on a USB drive at the time,
formatted w/ext3.
Reading the compaction code, it'll jump over pages marked as writeback,
but happily sit on locked buffer heads. If I'm reading the ext3 code
correctly, it still uses submit_bh directly on data=ordered writes,
without the working on the page bits.
The end result is that compaction stalls on all the data=ordered
writeback. We shouldn't see this with ext4 because it is using page
based writeback for the data=ordered. But, should we have a
buffer_migrate_page variant that returns busy for locked buffer heads?
-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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2013-01-04 13:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-04 13:23 Chris Mason [this message]
2013-01-07 19:14 ` compaction vs data=ordered on ext34 Jan Kara
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=20130104132305.GG14537@shiny \
--to=chris.mason@fusionio.com \
--cc=jack@suse.cz \
--cc=linux-mm@kvack.org \
--cc=srostedt@redhat.com \
--cc=tytso@mit.edu \
/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.