lkml.org 
[lkml]   [2002]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.[45] fixes for design locking bug in wait_on_page/wait_on_buffer/get_request_wait
Date
On Saturday 16 November 2002 17:59, Andrea Arcangeli wrote:

Hi Andrea,

> Your pausing problem have little to do with the pausing fix, the problem
> for you is the read latency, you're not triggering the race condition
> fixed by the pausing fix so it can't make differences. One of the
> foundamental obstacles to the read latency is the size of the I/O queue,
> factor that is workarounded by the read-latency patch that basically
> bypasses the size of the queue hiding the problem and in turn can't fix
> the write latency with O_SYNC and the read latency during true read aio
> etc...
ok, after some further tests, I think this is _somewhat_ FS dependent. I tried
this with ext2, ext3 (no difference there) and also with ReiserFS and what
must I say, those "Pausings" caused be the write latency doing it with
ReiserFS are alot less than with ext2|ext3 but are still occuring.

There must went in something bullshitty into 2.4.19/2.4.20 that causes those
ugly things because 2.4.18 does not have that problem. This is still why I
don't use any kernels >2.4.18.

After changing elevator things like this:

root@codeman:[/] # elvtune /dev/hda

/dev/hda elevator ID 0
read_latency: 2048
write_latency: 1024
max_bomb_segments: 0

those "pausings" are less worse than before but are still there.
NOTE: Write latency is lower than read latency (it's not a typo :)

ciao, Marc


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

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