Re: [resent PATCH] Re: very slow parallel read performance

Rik van Riel
2001-08-26T19:39:59Z

On Sun, 26 Aug 2001, Victor Yodaiken wrote:

> And scheduling gets even more complex as we try to account for work
> done in this thread on behalf of other processes. And, of course, we
> have all sorts of wacky merge problems

Actually, readahead is always done by the thread reading
the data, so this is not an issue.

> BTW: maybe I'm oversimplifying, but since read-ahead is an optimization
> trading memory space for time, why doesn't it just turn off when there's
> a shortage of free memory?
> num_pages = (num_requestd_pages + (there_is_a_boatload_of_free_space? readahead: 0)

When the VM load is high, the last thing you want to do is
shrink the size of your IO operations, this would only lead
to more disk seeks and possibly thrashing.

It would be nice to do something similar to TCP window
collapse for readahead, though...

This would work by increasing the readahead size every
time we reach the end of the last readahead window without
having to re-read data twice and collapsing the readahead
window if any of the pages we read in have to be read
twice before we got around to using them.

regards,

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/ http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)