Re: [PATCH] livelock in elevator scheduling

[kumon@flab.fujitsu.co.jp]

Jens Axboe writes:
 > On Tue, Nov 21 2000, kumon@flab.fujitsu.co.jp wrote:
 > > I never believe it intentional.  If it is true, the current kernel
 > > will be suffered from a kind of DOS attack.  Yes, actually I'm a
 > > victim of it.
 > 
 > The problem is caused by the too high sequence numbers in stock
 > kernel, as I said. Plus, the sequence decrementing doesn't take
 > request/buffer size into account. So the starvation _is_ limited,
 > the limit is just too high.

Yes, current limit is 1000000 and if I/O can manage 200req/s, then it
will expire 5000 sec after. So, I said "infinite (more than 1hour)".
Why do you add extreme priotity to lower sector accesses, which breaks
elevator scheduling idea?


 > If performance is down, then that problem is most likely elsewhere.
 > I/O limited benchmarking typically thrives on lots of request
 > latency -- with that comes better throughput for individual threads.

No, the performance down caused from this point.  Server benchmark has
a standard configuration workload which consists from several kind of
task, such as, CPU interntional, disk seq-read, seq-write, random-read,
random-write.

The benchmark invokes lots of processes, each corresponds to a client,
and each accesses different portion of few large files.  We have
enough memory to hold all dirty data at onece (1GB without himem), so
if no I/O blocking occur, all process can be run simultaneously with
limited amount of dirty flush I/O stream.

If some processes eagerly access relatively lower blocks, and other
process unfortunately requests higher block read, then the process is
blocked. Eventually this happens to large portion of processes, the
performance goes extremely down.
 During the measurement of test10 or test11, the performance is very
fluctuated and lots of idle time observed by vmstat. Such instability
is not observed on test1 or test2.

--
Computer Systems Laboratory, Fujitsu Labs.
kumon@flab.fujitsu.co.jp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/