summaryrefslogtreecommitdiffstats
path: root/net/ieee802154
diff options
context:
space:
mode:
authorShaohua Li <shaohua.li@intel.com>2009-11-03 20:25:02 +0100
committerJens Axboe <jens.axboe@oracle.com>2009-11-03 20:25:02 +0100
commit4b27e1bb442e964903f8a3fa6bdf33a602dc0941 (patch)
treed7eecb66f6a75dbff292fbd03b643b04ed075289 /net/ieee802154
parente6ec4fe24572ee265723d895ec4159e5559c8266 (diff)
downloadop-kernel-dev-4b27e1bb442e964903f8a3fa6bdf33a602dc0941.zip
op-kernel-dev-4b27e1bb442e964903f8a3fa6bdf33a602dc0941.tar.gz
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 'net/ieee802154')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud