lkml.org 
[lkml]   [2000]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Degrading disk read performance under 2.2.16
On Mon, Aug 14 2000, Corin Hartland-Swann wrote:
> I have tried this out, and found that the default settings were:
> elevator ID=232 read_latency=128 write_latency=8192 max_bomb_segments=4
>
> Can anyone point me to any documentation on this elevator code? I was
> wondering what exactly the different variables do...

Heh, I don't think there is any documentation. But essentially the
two latency variables set how many segments can supercede the request
when the elevator sorts in new requests. The max_bomb_segments controls
the max size of incoming writes, when there are read pendings for execution.

> I found that increasing the read_latency to match write_latency fixes the
> problems perfectly - thanks for the pointer!

Ok good. Andrea, could we bump read latency in 2.2.17-pre?
>
> Increasing the read_latency and write_latency to 10,000,000 results in
> similar throughput, but catastrophic seek performance:

Odd...

> Now, does anyone (Andrea in particular) know where the defaults are set? I

include/linux/blkdev.h, ELEVATOR_DEFAULTS.

> assume that setting read_latency to much lower than write_latency was an
> accident, but can't find whereabouts these values are allocated in the
> kernel. If this could be modified in the kernel then this would get disk
> performance back up to scratch...

I can't imagine this being an accident, I'm sure Andrea had some data
to backup the values chosen. But the current defaults do impose performance
problems, as they did in 2.4, so I think that up'ing read latency is
a good idea.

--
* Jens Axboe <axboe@suse.de>
* SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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