diff options
author | Shaohua Li <shaohua.li@intel.com> | 2009-11-03 20:25:02 +0100 |
---|---|---|
committer | Jens Axboe <jens.axboe@oracle.com> | 2009-11-03 20:25:02 +0100 |
commit | 4b27e1bb442e964903f8a3fa6bdf33a602dc0941 (patch) | |
tree | d7eecb66f6a75dbff292fbd03b643b04ed075289 /MAINTAINERS | |
parent | e6ec4fe24572ee265723d895ec4159e5559c8266 (diff) | |
download | linux-3.10-4b27e1bb442e964903f8a3fa6bdf33a602dc0941.tar.gz linux-3.10-4b27e1bb442e964903f8a3fa6bdf33a602dc0941.tar.bz2 linux-3.10-4b27e1bb442e964903f8a3fa6bdf33a602dc0941.zip |
cfq-iosched: limit coop preemption
CFQ has an optimization for cooperated applications. if several
io-context have close requests, they will get boost. But the
optimization get abused. Considering thread a, b, which work on one
file. a reads sectors s, s+2, s+4, ...; b reads sectors s+1, s+3, s
+5, ... Both a and b are sequential read, so they can open idle window.
a reads a sector s and goes to idle window and wakeup b. b reads sector
s+1, since in current implementation, cfq_should_preempt() thinks a and
b are cooperators, b will preempt a. b then reads sector s+1 and goes to
idle window and wakeup a. for the same reason, a will preempt b and
reads s+2. a and b will continue the circle. The circle will be very
long, and a and b will occupy whole disk queue. Other applications will
nearly have no chance to run.
Fix this limiting coop preempt until a queue is scheduled normally
again.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Acked-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions