On August 24, 2001 07:43 pm, Rik van Riel wrote:
> On Fri, 24 Aug 2001, Roger Larsson wrote:
>
> > I earlier questioned this too...
> > And I found out that read ahead was too short for modern disks.
> > This is a patch I did it does also enable the profiling, the only needed
> > line is the
> > -#define MAX_READAHEAD 31
> > +#define MAX_READAHEAD 511
> > I have not tried to push it further up since this resulted in virtually
> > equal total throughput for read two files than for read one.
>
> Note that this can have HORRIBLE effects if the total
> size of all the readahead windows combined doesn't fit
> in your memory.
>
> If you have 100 IO streams going on and you have space
> for 50 of them, you'll find yourself with 100 threads
> continuously pushing each other's read-ahead data out
> of RAM.
>
> 100 threads may sound much, but 100 clients really isn't
> that special for an ftp server...
>
> This effect is made a lot worse with the use-once
> strategy used in recent Linus kernels because:
>
> 1) under memory pressure, the inactive_dirty list is
> only as large as 1 second of pageout IO, meaning
^^^^^^^^
This is the problem. In the absense of competition and truly active pages,
the inactive queue should just grow until it is much larger than the active
ring. Then the replacement policy will naturally become fifo, which is
exactly what you want in your example.
Anyway, this is a theoretical problem, we haven't seen it in the wild yet, or
a test load that demonstrates it.
> the sum of the readahead windows is smaller than
> with a kernel which doesn't do the use-once thing
> (eg. Alan's kernel)
>
> 2) the drop-behind strategy makes it much more likely
> that we'll replace the data we already used, instead
> of the read-ahead data we haven't used yet ... this
> means the data we are about to use has a better chance
> to be in memory
-- Daniel - 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/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:14 EST