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
On Mon, 27 Aug 2001, Alex Bligh - linux-kernel wrote:

> 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.

There you are perfectly right. I misunderstood. How do you measure cost of
replacement ?

> 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.

Do we need a maximum readahead based on reasonable latency of the device
in question ?
If on the other hand a task is very fast in processing its buffers the
readahead queue will _not_ be long. The task will however use a lot of IO
bandwidth. Strictly speaking this is a question of IO scheduling.

Regards
Oliver


-
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.121 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site