[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.022 / U:20.100 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site