Date: Fri, 17 Nov 1995 12:13:38 +1100 From: George Scott <george@moa.cc.monash.edu.au> To: freebsd-current@FreeBSD.org Subject: Re: Disk I/O that binds Message-ID: <199511170113.MAA02108@moa.cc.monash.edu.au>
next in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > Last I checked it was a double que elevator sort... > any block requewsted that is behind you gets put in the "next pass" > queue, and anything in front of you get's put in front of you in the > "present pass" queue.. direction of travel never changes.. > (I just checked again, it hasn't changed) > > It's possible that if one process has started reading a large file that was > read onto the disk sequentially, then otehr processes may starve.. > it goes like this: > > process 1 reads block x, and the readahead puts in a request for block x+1 > process 1 reads plock x+1, readahead inserts block x+2 > > etc. > > > as the disk is walking slowely forwards along the disk, any process looking for a block BEFORE x is missing out.. > this should only be a problem for systems where the cpu is fast enough > to deal with the present block and put it's request for the next one in before the disk has completed transfer of the readahead block. > In effect the faster the system, the more problem you're going to have... What would happen if the requests were broken up into cylinders (preferably physical but arbitrary would probably work too) and the new request only added to the "present pass" queue if it's *cylinder* was greater than the cylinder of the request at the head of the queue? In other words, once the drive has started to process a cylinder new requests for that cylinder get added to the "next pass" queue. For the case where many processes are requesting random blocks from all over the disk you probably wouldn't notice much difference from the current algorithm. For the case where there is one process reading a large file from front to back and no other disk activity that process would see no difference; its next request would be added to the front of an empty queue. For the case where there is one process reading a large file from front to back and other processes requesting random blocks from all over the disk the one process would get a steady stream of blocks along with everyone else. The readahead would help but wouldn't be able to monopolise the disk; in the example above when the process reads block x, blocks x and x+1 get added to the "present pass" queue, when it reads x+1 the readahead would add block x+2 to the "next pass" queue. George. --------------------------------------------------------------------- George Scott Senior Systems Programmer Caulfield Computer Centre Email: George.Scott@cc.monash.edu.au Monash University Fax : +61 3 9903 2100 900 Dandenong Road Voice: +61 3 9903 2248 Caulfield East, 3145 Victoria, Australia
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511170113.MAA02108>