From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 78651] Write performance of ext4 degrades linearly as volume fills
Date: Sun, 22 Jun 2014 23:18:10 +0000 [thread overview]
Message-ID: <bug-78651-13602-CsIw79ZmUN@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-78651-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=78651
--- Comment #2 from Joseph D. Wagner <joe@josephdwagner.info> ---
I changed the script to run "perf record" on the dump command. I turned
tracing on for all jbd2 and ext4 events. (I had to stop it about half way
through, because the perf.data file was getting too big.) All non-zero results
are below.
Are some of these events supposed to be balanced? For example, there were 8
ext4:ext4_es_shrink_enter, but 0 ext4:ext4_es_shrink_exit. I'm wondering if
some of this code is being called recursively without proper unwinding. It
could explain the recursive loss in performance.
499M ext4:ext4_journal_start: 356 chunks LOST!
252M jbd2:jbd2_handle_stats: 4 chunks LOST!
252M jbd2:jbd2_handle_start: 1 chunks LOST!
252M ext4:ext4_mark_inode_dirty: 3 chunks LOST!
246M ext4:ext4_ext_show_extent: 1 chunks LOST!
246M ext4:ext4_ext_map_blocks_exit: 1 chunks LOST!
246M ext4:ext4_ext_map_blocks_enter: 26 chunks LOST!
246M ext4:ext4_es_lookup_extent_exit
246M ext4:ext4_es_lookup_extent_enter: 1 chunks LOST!
246M ext4:ext4_es_insert_extent
246M ext4:ext4_da_write_end: 6 chunks LOST!
246M ext4:ext4_da_write_begin: 441 chunks LOST!
246M ext4:ext4_da_reserve_space
150 ext4:ext4_drop_inode
77 ext4:ext4_releasepage
17 ext4:ext4_es_cache_extent
8 ext4:ext4_sync_fs
8 ext4:ext4_es_shrink_enter
5 ext4:ext4_es_find_delayed_extent_range_exit
5 ext4:ext4_es_find_delayed_extent_range_enter
3 ext4:ext4_request_inode
3 ext4:ext4_allocate_inode
2 ext4:ext4_ext_load_extent
--
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2014-06-22 23:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-22 5:44 [Bug 78651] New: Write performance of ext4 degrades linearly as volume fills bugzilla-daemon
2014-06-22 5:45 ` [Bug 78651] " bugzilla-daemon
2014-06-22 23:18 ` bugzilla-daemon [this message]
2014-07-05 17:14 ` bugzilla-daemon
2014-07-06 12:52 ` bugzilla-daemon
2014-07-06 17:57 ` bugzilla-daemon
2014-07-07 6:00 ` bugzilla-daemon
2014-07-07 6:53 ` bugzilla-daemon
2014-07-07 12:29 ` bugzilla-daemon
2014-07-08 13:42 ` bugzilla-daemon
2014-07-08 13:42 ` bugzilla-daemon
2014-07-08 13:43 ` bugzilla-daemon
2014-07-08 13:43 ` bugzilla-daemon
2014-07-08 13:43 ` bugzilla-daemon
2014-07-08 14:23 ` bugzilla-daemon
2014-07-09 3:27 ` bugzilla-daemon
2014-07-09 3:30 ` bugzilla-daemon
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=bug-78651-13602-CsIw79ZmUN@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-ext4@vger.kernel.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 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.