diff options
| author | Jens Axboe <jens.axboe@oracle.com> | 2009-04-14 14:18:16 +0200 |
|---|---|---|
| committer | Jens Axboe <jens.axboe@oracle.com> | 2009-04-15 08:28:12 +0200 |
| commit | d6ceb25e8d8bccf826848c2621a50d02c0a7f4ae (patch) | |
| tree | 31dec01cb624b27a1c29a5886dd801a67bba525e /block/scsi_ioctl.c | |
| parent | buffer: switch do_emergency_thaw() away from pdflush_operation() (diff) | |
| download | linux-d6ceb25e8d8bccf826848c2621a50d02c0a7f4ae.tar.xz linux-d6ceb25e8d8bccf826848c2621a50d02c0a7f4ae.zip | |
cfq-iosched: don't delay queue kick for a merged request
"Zhang, Yanmin" <yanmin_zhang@linux.intel.com> reports that commit
b029195dda0129b427c6e579a3bb3ae752da3a93 introduced a regression
of about 50% with sequential threaded read workloads. The test
case is:
tiotest -k0 -k1 -k3 -f 80 -t 32
which starts 32 threads each reading a 80MB file. Twiddle the kick
queue logic so that we do start IO immediately, if it appears to be
a fully merged request. We can't really detect that, so just check
if the request is bigger than a page or not. The assumption is that
since single bio issues will first queue a single request with just
one page attached and then later do merges on that, if we already
have more than a page worth of data in the request, then the request
is most likely good to go.
Verified that this doesn't cause a regression with the test case that
commit b029195dda0129b427c6e579a3bb3ae752da3a93 was fixing. It does not,
we still see maximum sized requests for the queue-then-merge cases.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Diffstat (limited to 'block/scsi_ioctl.c')
0 files changed, 0 insertions, 0 deletions