Messages in this thread | | | Date | Sun, 26 Aug 2001 12:59:11 -0600 | From | Victor Yodaiken <> | Subject | Re: [resent PATCH] Re: very slow parallel read performance |
| |
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/
| |