From: Shaohua Li <shaohua.li@intel.com>
To: lkml <linux-kernel@vger.kernel.org>, linux-scsi@vger.kernel.org
Cc: JBottomley@Parallels.com, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@infradead.org>, Ted Ts'o <tytso@mit.edu>,
"Wu, Fengguang" <fengguang.wu@intel.com>,
"Darrick J. Wong" <djwong@us.ibm.com>
Subject: [patch 0/2]scsi: improve fairness of starved list
Date: Thu, 22 Dec 2011 11:10:08 +0800 [thread overview]
Message-ID: <1324523408.22361.470.camel@sli10-conroe> (raw)
We recently found some performance regressions related to writeback.
See http://marc.info/?l=linux-kernel&m=132391033818515&w=2. The test
system uses a LSI 1068e card and 12 hard disks attached to it. The
workload is a simple FIO test, which runs one thread for each disk to
create files. The filesystem is EXT4. Compared to 3.1 kernel, we found
both data=order and data=writeback mode have performance regression.
data=writeback regression is bigger.
The scsi_host->can_queue = 127, where disk queue_depth=64, 64*12 > 127,
so the fairness to utilize host can_queue is important for the overall
throughput, otherwise some disks will be starved and others run in full
speed. In this workload, we found recent I/O less writeback causes the
fairness issue and the throughput get dropped.
We'd better fix the fairness issue in writeback, but on the other hand,
the scsi layer also has fairness issue regarding to the starve list,
which exists in old kernel too, but not that severe. Below two patches
try to address the scsi issue, the test result is (average of 3 runs,
data=writeback mode):
3.1: 1000045 KB/s
base: 854016 KB/s
base+patch: 958122 KB/s
The patches don't fully recover the regression, but give a 12%
improvement.
Thanks,
Shaohua
reply other threads:[~2011-12-22 2:56 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1324523408.22361.470.camel@sli10-conroe \
--to=shaohua.li@intel.com \
--cc=JBottomley@Parallels.com \
--cc=axboe@kernel.dk \
--cc=djwong@us.ibm.com \
--cc=fengguang.wu@intel.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox