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;