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

[Victor Yodaiken <yodaiken@fsmlabs.com>]

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)