Messages in this thread | | | Subject | Re: elevator algorithm bug in ll_rw_blk.c | Date | Fri, 13 Nov 1998 13:02:57 -0600 (EST) | From | kwrohrer@ce ... |
| |
And lo, Jamie Lokier saith unto me: > > > Chris Wedgwood <chris@cybernet.co.nz> writes: > > The 'obvious' solution is to sort the dirty block list, but you'll > > need to do it carefully to avoid starvation. > > I understand sorting the block list. What is the issue with starvation? > Let's say I'm copying a large file from some other disk; if we've got contiguous free space, and as long as I can read at least as fast as I can write, the file I'm creating will always include the next closest blocks. No other pending writes will occur until I'm done, because they're farther away on the disk than the rest of this file will be.
If you sort only those requests currently in the queue, then do those requests in sorted order before performing any subsequently received requests, you can keep this sort of starvation under a little control. If, on completion of each request, always do the next {highest|lowest} block, then a group of processes writing to a "popular" area of the disk can "capture" the disk for a long while, and a single process doing a long contiguous read or write can capture the disk until it's done.
This is especially important nowadays, as transfer time, average seek time, and rotational latency fall but minimum seek time and head switch time have risen significantly over the past few years...
Keith
-- "The avalanche has already started; |Linux: http://www.linuxhq.com |"Zooty, it is too late for the pebbles to |KDE: http://www.kde.org | zoot vote." Kosh, "Believers", Babylon 5 |Keith: kwrohrer@enteract.com | zoot!" www.midwinter.com/lurk/lurker.html |http://www.enteract.com/~kwrohrer | --Rebo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |