[lkml]   [2001]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [resent PATCH] Re: very slow parallel read performance
On Sat, 25 Aug 2001, Daniel Phillips wrote:

> > The queue looks like this, with new pages being added to the
> > front and old pages being dropped off the right side:
> > AAaaBBbbCCccDDdd
> >
> > With the current use-once thing, we will end up dropping ALL
> > pages from file D, even the ones we are about to use (DDdd).
> I call that gracefull. Look, you only lost 2 pages out of 16, and
> when you have to re-read them it will be a clustered read. It's just
> not that big a deal.

The difference is that with the use-once idea file D would
lose all 4 pages, while with the drop-behind idea every file
would use one page it had already used.

> > With drop-behind we'll drop four pages we have already used,
> > without affecting the pages we are about to use (dcba).
> Well, yes, but you will also drop that header file your compiler wants
> to read over and over. How do you tell the difference? There are
> lots of nice things you can do if your algorithm can assume
> omniscience.

Agreed, this thing should be fixed. I'm sure we'll come
up with a way to get around this problem.

> My point is, even with the case you supplied the expected behaviour of
> the existing algorithm is acceptable. There is no burning fire to put
> out, not here anyway.

True, it's just an issue of performance and heavily used
servers falling over under load, nothing as serious as
data corruption or system instability.


IA64: a worthy successor to i860.

Send all your spam to (spam digging piggy)

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 12:58    [W:1.302 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site