[lkml]   [2002]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Poor read performance when sequential write presents
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
> 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

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

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