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)
- 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:20 EST