[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: Terrible elevator performance in kernel 2.4.0-test8

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


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
> 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
> Please read the FAQ at
--- 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;
+ run_task_queue(&tq_disk);

prev = current;
this_cpu = prev->processor;
 \ /
  Last update: 2005-03-22 12:38    [W:0.041 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site