Giuliano Pochini wrote:
>
> >> I did a IO test with one sequential read and one sequential write
> >> to different files. I expected somewhat similar throughput on read
> >> and write. But it seemed that the read is blocked until the write
> >> finishes. After the write process finished, the read process slowly
> >> picks up the speed. Is Linux buffer cache in favor of write? How
> >> to tune it?
> > [...]
> > 2: Apply http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.19-pre5/read-latency2.patch
>
> Hmmm, someone wrote a patch to fix another related problem: the fact
> that multiple readers read at a very different speed. It's not unusual
> that one reader gets stuck until all other have finished. I don't
> remember who wrote that patch, sorry.
Oh absolutely. That's the reason why 2.4 is beating 2.5 at tiobench with
more than one thread. 2.5 is alternating fairly between threads and 2.4
is not. So 2.4 seeks less.
I've been testing this extensively on 2.5 + multipage BIO I/O and when you
increase readahead from 32 pages (two BIOs) to 64 pages (4 BIOs), 2.5 goes
from perfect to horrid - each threads grabs the disk head and performs many,
many megabytes of read before any other thread gets a share. Net effect is
that the tiobench numbers are great, but any operation which involves
reading disk has 30 or 60 second latencies.
Interestingly, it seems specific to IDE. SCSI behaves well.
I have tons of traces and debug code - I'll bug Jens about this in a week or
so.
-
-
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/
This archive was generated by hypermail 2b29 : Fri May 31 2002 - 22:00:12 EST