From: "Török Edwin" <edwintorok@gmail.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: xfs@oss.sgi.com
Subject: Marking inode dirty latency > 1000 msec on XFS!
Date: Fri, 15 Feb 2008 20:44:44 +0200 [thread overview]
Message-ID: <47B5DD9C.3080906@gmail.com> (raw)
Hi,
Using LatencyTOP 0.3, on the latest 2.6.25-git I see latencies of over a
second on __mark_ inode_dirty.
[see a stacktrace at end of this email]
I tried to locate xfs's implementation of super_operations.dirty_inode,
but it isn't specified in xfs_super.c.
I don't know how mark_inode_dirty ends up calling xfs_trans_commit, but
is it required to commit the dirty status of an inode to the transaction
log?
FWIW, this is a slow laptop hdd (5400 rpm, ST96812AS), but latency of 1
second is still big.
Are there any settings I can tweak to reduce latency?
LatencyTOP output during a 'svn up' on llvm-gcc source tree:
Cause Maximum Percentage
Marking inode dirty 1105.8 msec 7.8 %
_xfs_buf_ioapply default_wake_function xlog_state_1065.2 msec 7.0 %
Deleting an inode 964.8 msec 20.0 %
_xfs_buf_ioapply default_wake_function xlog_state_780.1 msec 8.3 %
_xfs_buf_ioapply default_wake_function xlog_state_679.4 msec 3.3 %
_xfs_buf_ioapply default_wake_function xlog_state_610.1 msec 5.6 %
XFS I/O wait 585.9 msec 12.6 %
_xfs_buf_ioapply default_wake_function xlog_state_528.8 msec 6.8 %
Creating block layer request 499.6 msec 5.7 %
Earlier I've seen this latencyTOP output too:
Cause Maximum Percentage
XFS I/O wait 407.6 msec 53.4 %
Marking inode dirty 173.0 msec 0.9 %
Writing a page to disk 141.6 msec 42.6 %
__generic_unplug_device default_wake_function xfs_ 86.0 msec 0.3 %
Page fault 44.1 msec 0.2 %
kobject_put put_device blk_start_queueing __generi 15.9 msec 0.1 %
Scheduler: waiting for cpubuf_find kmem_zone_alloc 12.4 msec 2.2 %
put_device scsi_request_fn blk_start_queueing defa 4.9 msec 0.0 %
Waiting for event (poll) 4.7 msec 0.4 %
Process svn (10685)
Writing a page to disk 23.9 msec 55.9 %
XFS I/O wait 15.9 msec 35.2 %
Scheduler: waiting for cpu 0.8 msec 8.9 %
Raw output from /proc/latency shows stacktrace:
7 93862 26567 _xfs_buf_ioapply default_wake_function
xlog_state_get_iclog_space xlog_state_release_iclog xlog_write
xfs_log_write _xfs_trans_commit __mark_inode_dirty igrab xfs_create
xfs_vn_mknod security_inode_permission
1 96331 96331 default_wake_function xlog_state_get_iclog_space
xlog_state_release_iclog xlog_write xfs_log_write _xfs_trans_commit
__mark_inode_dirty igrab xfs_create xfs_vn_mknod
security_inode_permission xfs_vn_permission
Best regards,
--Edwin
next reply other threads:[~2008-02-15 18:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-15 18:44 Török Edwin [this message]
2008-02-22 6:31 ` Marking inode dirty latency > 1000 msec on XFS! Lachlan McIlroy
2008-02-22 7:16 ` David Chinner
2008-02-22 8:40 ` Török Edwin
2008-02-22 8:59 ` Török Edwin
2008-02-22 10:20 ` Török Edwin
2008-02-23 0:06 ` David Chinner
2008-02-23 9:41 ` Török Edwin
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=47B5DD9C.3080906@gmail.com \
--to=edwintorok@gmail.com \
--cc=arjan@linux.intel.com \
--cc=xfs@oss.sgi.com \
/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