lkml.org 
[lkml]   [2001]   [Aug]   [24]   [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 Fri, 24 Aug 2001, Rik van Riel wrote:

> On Fri, 24 Aug 2001, Roger Larsson wrote:
>
> > Not having the patch gives you another effect - disk arm is
> > moving from track to track in a furiously tempo...
>
> Fully agreed, but remember that when you reach the point
> where the readahead windows are pushing each other out
> you'll be off even worse.
>
> I guess in the long run we should have automatic collapse
> of the readahead window when we find that readahead window
> thrashing is going on, in the short term I think it is
> enough to have the maximum readahead size tunable in /proc,
> like what is happening in the -ac kernels.

There is some minimal heuristics in the readahead code that tries to
reduce the windows if things donnot work as expected. I donnot remember
exactly as they work. May-be I should re-read the code. What the code
wants is to perform *asynchronous* read-ahead in order to elimate IO
latency for sequential IO streaming patterns.

For hard disks connected to a fast HBA, large read-ahead is not necessary.
For example, un Cheetah drive can handle more than 8000 short IOs per
second and a SYMBIOS chip using the SYM53C8XX driver can handle more than
15000 short IOs per seconds.

The larger the read-ahead chunks, the more likely trashing will occur. In
my opinion, using more than 128 K IO chunks will not improve performances
with modern hard disks connected to a reasonnably fast controller, but
will increase memory pressure and probably thrashing.

It is a different story for some external RAID boxes that may perform
better using hudge IO chunks. Such boxes have poor firmware in my opinion.

Some tunability of the read-ahead algorithm will be useful for sure, but
not that much, in my opinion. I am under the impression that using some
MAX READ AHEAD value in the range 64K-128K and given the current
heuristics in the code, a subsystem using hard disks connected to a decent
controller will perform close to the best for most IO patterns. This let
me think, that there is no miracle to expect from a tunability of the
read-ahead. (Excepted if stupid external RAID boxes are involved,
obviously).

Regards,
Gérard.

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