lkml.org 
[lkml]   [2001]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [resent PATCH] Re: very slow parallel read performance
    Oliver,

    --On Monday, 27 August, 2001 10:03 PM +0200 Oliver Neukum
    <Oliver.Neukum@lrz.uni-muenchen.de> wrote:

    > what leads you to this conclusion ?
    > A task that needs little time to process data it reads in is hurt much
    > more by added latency due to a disk read.

    I meant that dropping readahed pages from dd from a floppy (or
    slow network connection) is going to cost more to replace
    than dropping the same number of readahead pages from dd from
    a fast HD. By fast, I meant fast to read in from the file.

    If the task is slow, because it's CPU bound (or bound by
    other I/O), and /that/ causes the stream to be slow to
    empty, then as you say, we have the opposite problem.
    On the other hand, it might only be a fast reading task
    compared to others as other tasks are blocking on stuff
    requiring memory, and all the memory is allocated to that
    stream's readahead buffer. So penalizing slow tasks and
    prioritizing fast ones may cause an avalanche effect.

    Complicated.

    --
    Alex Bligh
    -
    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 12:58    [W:0.022 / U:0.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site