On Sun, Aug 26, 2001 at 06:54:55PM +0200, Daniel Phillips wrote:
> But it's a very interesting idea: instead of performing readahead in
> generic_file_read the user thread would calculate the readahead window
> information and pass it off to a kernel thread dedicated to readahead.
> This thread can make an informed, global decision on how much IO to
> submit. The user thread benefits by avoiding some stalls due to
> readahead->readpage, as well as avoiding thrashing due to excessive
> readahead.
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
Process Kthread
----------------------------
read block 1
schedules to read block 2 readahead
read block 2
not in cache so
send to ll_rw
get it.
exit
getting through the backlog, don't see block 2 anywhere
so do the readahead not knowing that it's already been
read, used, and discarded
Sound like it could keep you busy for a while.
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)
-
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