lkml.org 
[lkml]   [1998]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: elevator algorithm bug in ll_rw_blk.c
From
Date
"Stephen C. Tweedie" <sct@redhat.com> writes:
>
> The way it actually works, sequential writes tend to be kept in
> sequential order in the buffer cache lists, so the typical cases work
> pretty well. All the benchmarks show that sequential filesystem writes
> work very well.
>

Unfortunately, there's a case where it frequently works very very
badly; That's when you have a LOT of disk cache (150 - 200meg) and a
fast writer producing a lot of data).

In this case, the write performance frequently goes abysmal, even tho
it's sequential writing. 'Abysmal' to the tune on 800K/sec on a 6 disk
array.

(the actual performance case I saw this frequently on was a squid-1.1
server shutting down. It would write 6 x 200Meg file, one to each of
the 6 disks).

I'm still not sure exactly what was happening, but the write
performance would start of in the 4 or 5 meg/sec for the first 10 or
so seconds, then drop to 800K/sec for the remainder of the
data. Furious seeking occured during this time. I suspect the probem
was that it was writing different points in the file, and because the
window wasn't large enough, not noticing that it would have been
better off just writing from the one point.

Michael.

-
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:45    [W:1.556 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site