[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject(reiserfs) Re: More on 2.2.18pre2aa2
On Tue, 12 Sep 2000, Rik van Riel wrote:

>But you don't. Transfer rate is very much dependant on the
>kind of load you're putting on the disk...

Transfer rate means `hdparm -t` in single user mode. Try it and you'll see
you'll get always the same result.

>Throughput really isn't that relevant here. The problems are

Thoughput is relevant. Again, how do you get a 1msec latency out of a
blockdevice that writes 1 request every two seconds?

>With equally horrible results for most machines I've
>seen. For a while I actually thought the bug /must/
>have been somewhere else because I saw processes
>'hanging' for about 10 minutes before making progress
>again ...

As said in my earlier email the current 2.4.x elevator scheduler is
_disabled_. I repeat: you should change include/linux/elevator.h and set
the read and write latency to 250 and 500 respectively. You won't get
latency as good as in test1, but it won't hang for 10 minutes.

I and Jens sent a patch to Linus to reenable that push fixing some other
problem of the blkdev merging reported by Giuliano Pochini, plus wake-one
flow control, plus I fixed the DMA_CHUNK_SIZE thing that was buggy and
it's still buggy in the sparc64 case (I didn't fixed sparc64 in my patch,
the DMA_CHUNK_SIZE should limit the segments to
max(64,SHpnt->sg_tablesize) and not to 64 as now), plus it allowed 512K
sized SCSI commands, plus some other minor thing but it didn't get merged.

>Not really. What about just using something like
>"half a second, but at least 10 requests liberty to
>reorder" ?

I doesn't make sense.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.175 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site