For a while, Ive been seeing a performance problem with 2.4.0-test
kernels.
The benchmark I am using is an netatalk performance benchmark.
But I think this is a general performance problem, not appletalk
related.
The benchmark has a varying number of clients reading and writing 30 Meg
files.
The symptom I see is that with more an 2 or 3 clients, I see a suddent
and gigantic reduction in write performance. At the same time I can hear
the disk seeking wildly. And the throughput reported by "vmstat 5" drops
from 2000-3000 to 100-200.
What I believe is happening is that the elevator isn't merging the
requests properly.
I think that this may be the same problem reported here
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0008.2/0389.html
When stracing the netatalk servers, I can see that they are reading from
the network then doing an 8k write and repeating.
If I try to simulate the problem by running multiple iozones doing 8k
writes, I dont see the same kind of problems.
However, in a non networked benchmark like iozone, each process is doing
many writes in its timeslice. And these writes coalesce naturally.
In the networked benchmark, the read from the network is introducting
enough delay that we get a context switch and the writes to different
files become interleaved.
This is precisely the sort of situation that the elevator is supposed to
help with.
With kernel version 2.4.0-test1-ac22, I saw adequate performance.
In this version, the default elevator settings had a max_bomb value of
32.
In 2.4.0-test3 - test6, the default max_bombs value became 0. And the
performance with this setting was terrible.
If I increase max_bombs with elvtune, the performance markedly improves.
Although I still saw a tendency for a client to get write starved.
In 2.4.0-test, the max_bombs value has been eliminated so I can't change
it. I was hoping that that meant that the algorithm had been improved.
Unfortunately, the benchmarks don't show any improvement.
-- Robert Cohen Unix Support, TLTSU Australian National University - 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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:23 EST