i'm seeing similar problems. I think these problems started when the
elevator was rewritten, i believe it broke the proper unplugging of IO
devices. Does your performance problem get fixed by the attached
workaround?
Ingo
On Thu, 14 Sep 2000, Robert Cohen wrote:
> 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 [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
--- linux/kernel/sched.c.orig Sun Sep 3 10:03:35 2000
+++ linux/kernel/sched.c Mon Sep 4 09:23:07 2000
@@ -508,6 +508,7 @@
if (tq_scheduler)
goto handle_tq_scheduler;
tq_scheduler_back:
+ run_task_queue(&tq_disk);
prev = current;
this_cpu = prev->processor;
