]> git.baikalelectronics.ru Git - kernel.git/commit
cfq-iosched: don't delay queue kick for a merged request
authorJens Axboe <jens.axboe@oracle.com>
Tue, 14 Apr 2009 12:18:16 +0000 (14:18 +0200)
committerJens Axboe <jens.axboe@oracle.com>
Wed, 15 Apr 2009 06:28:12 +0000 (08:28 +0200)
commit0c1024ec068e61b50419bc41779fa8489e190491
tree31dec01cb624b27a1c29a5886dd801a67bba525e
parent874af5e4f7d5ce01071d1c0e35c53ef3e2f224b3
cfq-iosched: don't delay queue kick for a merged request

"Zhang, Yanmin" <yanmin_zhang@linux.intel.com> reports that commit
daff4615ee41e06957291bad8013cfca9c3ebde9 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 daff4615ee41e06957291bad8013cfca9c3ebde9 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>
block/cfq-iosched.c