aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/jbd.h
diff options
context:
space:
mode:
authorJan Kara <jack@suse.cz>2011-02-21 11:25:37 -0500
committerJan Kara <jack@suse.cz>2012-04-11 05:12:44 -0400
commit2db938bee32e7469ca8ed9bfb3a05535f28c680d (patch)
tree7d175a486c2e02270839ba18da61455603c2205e /include/linux/jbd.h
parent923e9a1399b620d063cd88537c64561bc3d5f905 (diff)
jbd: Refine commit writeout logic
Currently we write out all journal buffers in WRITE_SYNC mode. This improves performance for fsync heavy workloads but hinders performance when writes are mostly asynchronous, most noticably it slows down readers and users complain about slow desktop response etc. So submit writes as asynchronous in the normal case and only submit writes as WRITE_SYNC if we detect someone is waiting for current transaction commit. I've gathered some numbers to back this change. The first is the read latency test. It measures time to read 1 MB after several seconds of sleeping in presence of streaming writes. Top 10 times (out of 90) in us: Before After 2131586 697473 1709932 557487 1564598 535642 1480462 347573 1478579 323153 1408496 222181 1388960 181273 1329565 181070 1252486 172832 1223265 172278 Average: 619377 82180 So the improvement in both maximum and average latency is massive. I've measured fsync throughput by: fs_mark -n 100 -t 1 -s 16384 -d /mnt/fsync/ -S 1 -L 4 in presence of streaming reader. The numbers (fsyncs/s) are: Before After 9.9 6.3 6.8 6.0 6.3 6.2 5.8 6.1 So fsync performance seems unharmed by this change. Signed-off-by: Jan Kara <jack@suse.cz>
Diffstat (limited to 'include/linux/jbd.h')
-rw-r--r--include/linux/jbd.h15
1 files changed, 9 insertions, 6 deletions
diff --git a/include/linux/jbd.h b/include/linux/jbd.h
index d211732b9e99..f265682ae134 100644
--- a/include/linux/jbd.h
+++ b/include/linux/jbd.h
@@ -479,12 +479,6 @@ struct transaction_s
479 * How many handles used this transaction? [t_handle_lock] 479 * How many handles used this transaction? [t_handle_lock]
480 */ 480 */
481 int t_handle_count; 481 int t_handle_count;
482
483 /*
484 * This transaction is being forced and some process is
485 * waiting for it to finish.
486 */
487 unsigned int t_synchronous_commit:1;
488}; 482};
489 483
490/** 484/**
@@ -531,6 +525,8 @@ struct transaction_s
531 * transaction 525 * transaction
532 * @j_commit_request: Sequence number of the most recent transaction wanting 526 * @j_commit_request: Sequence number of the most recent transaction wanting
533 * commit 527 * commit
528 * @j_commit_waited: Sequence number of the most recent transaction someone
529 * is waiting for to commit.
534 * @j_uuid: Uuid of client object. 530 * @j_uuid: Uuid of client object.
535 * @j_task: Pointer to the current commit thread for this journal 531 * @j_task: Pointer to the current commit thread for this journal
536 * @j_max_transaction_buffers: Maximum number of metadata buffers to allow in a 532 * @j_max_transaction_buffers: Maximum number of metadata buffers to allow in a
@@ -696,6 +692,13 @@ struct journal_s
696 tid_t j_commit_request; 692 tid_t j_commit_request;
697 693
698 /* 694 /*
695 * Sequence number of the most recent transaction someone is waiting
696 * for to commit.
697 * [j_state_lock]
698 */
699 tid_t j_commit_waited;
700
701 /*
699 * Journal uuid: identifies the object (filesystem, LVM volume etc) 702 * Journal uuid: identifies the object (filesystem, LVM volume etc)
700 * backed by this journal. This will eventually be replaced by an array 703 * backed by this journal. This will eventually be replaced by an array
701 * of uuids, allowing us to index multiple devices within a single 704 * of uuids, allowing us to index multiple devices within a single