Messages in this thread | | | Date | Fri, 19 Mar 1999 15:45:11 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: disk head scheduling |
| |
On Fri, 19 Mar 1999, Arvind Sankar wrote:
> On Fri, Mar 19, 1999 at 10:41:31AM -0800, David Lang wrote: > > > Well of course a 2-way elevator should sort by *ascending* sector within > > > descending track. I take it this is difficult? > > > > > > -- > > > > Many (most? all new?) IDE drives lie to you about the real > > heads/sectors of the drive so you do not have the ability to do this > > accuratly. > > > > Yeah, but some manufacturers are good enough to put it in the tech notes. > Should the scheduling algo be put in as a device strategy function, with > fallback to the current elevator if the device doesnt have one? Then we could > implement two way elevator algos for those hard disks for which we can get > physical geometry info from the data sheets or somewhere. >
The typical IDE drive has a single platter and two heads. Just like a floppy disk. The so-called geometry is specified only for compatibility with the real-mode BIOS (0x13) interface that expects heads/sectors/cylinders, like in the old ST-506 interface days.
Any attempt to optimize performance based upon this phony geometry will fail. The best you can do is attempt to keep read/write queues separate. In other words, if possible, queue a bunch of reads and do them all together, then queue a bunch of writes and queue them all together. This can cut down some time on the write-splice and other so-called rotational latencies.
A write splice occurs when you need to write some new sectors between existing sectors, i.e., you are not going to write an entire track. This often requires that the disc make up to one complete rotation before a write can begin because the drive has to "learn" where the starting sector is by reading sectors. Note, all sectors on hard disks are "soft" which means that there is no index to tell the electronics when to turn on the write current. If writes get queued together, and you have multiple writes, there is a chance some writes will occur on the same track. This means that since the drive already knows where the sectors are on that track, it doesn't have to reread.
There is practically zero probability that optimization based upon phony geometry will accomplish anything because the real geometry boundaries are usually well hidden by the drive's sector buffer. All you do is waste CPU cycles that could be used elsewhere. What happens is you slightly slow the overall operation of the entire machine without increasing the Disc performance at all. Wasted CPU cycles are never gotten back, you burned them up, making a beautiful I/O queue, then accomplish nothing for your effort.
With SCSI drives, the physical geometry is also hidden. However since SCSI drives usually cost more, the expense of better buffering is usually justified. Therefore the drives themselves become very "smart". Usually an internal CPU optimizes reads and writes if you let it. You let it by using a controller which provides tagged queuing, synchronous operation, and disconnect.
If the OS/Driver combination keeps the queues full, performance will be optimized for a particular drive.
Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.2.3 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology.
- 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/
| |