[lkml]   [1999]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: disk head scheduling
On Fri, 19 Mar 1999, Arvind Sankar wrote:

> On Fri, Mar 19, 1999 at 03:45:11PM -0500, Richard B. Johnson wrote:
> > On Fri, 19 Mar 1999, Arvind Sankar wrote:
> > > 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.
> > >
> >
> IBM claims that my hard disk (Model IBM DHEA-38451) has 4 platters and 8 heads.
> I assume these are physical, since there are either 15 or 16 logical heads in
> CHS mode (settable via jumpers).
> >
> > 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.
> Who's talking about optimizing based on phony geometries? Did you read what
> I wrote?

You just wrote it. Even though I worked for a major disk manufacturer
I don't know what you will say in the future.

As I explained, most IDE geometries are phony for compatability with
the H/C/S acessible through the BIOS.

> > 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.
> I don't get this. If this were true, then the average latency of a disk would
> be the time for one complete rotation (half a rotation to find the start, and
> half a rotation to actually get to the right place). But the average latency is
> equal to _half_ the time for a complete rotation.

The average latency is something you expect when you see a head spinning
over a platter. However, it is some invention rather than fact. This is
why we have sector interleave. There are few (if any) IDE drives that
can read or write an entire track in one revolution. The high bit-density
and low bandwidth I/O path almost guarantees that you can't get the data
out of a sector buffer fast enough. Therefore sectors are interleaved.
The real number of sectors is almost always a prime number so that an
interleave of 2,3,4,5 or greater can be used. The manufacturer formats
the drive with the interleave that matches the sector-to-sector time
against the I/O bandwidth.

In fact, I have written utilities that determine the optimum interleave
and format the drive to that value.

> Bunching requests that are on the same track is good, since the drive
> probably does some read-ahead and caching. But accesses that are far enough
> apart that they can't be to the same track can be done in either order with
> no significant difference in time.

I don't think IDE drives do read ahead and caching. Look at the
electronics. There is just a servo chip, a read/write amplifier,
serializer, and a static-RAM sector buffer. IDE means Integrated
Drive Electronics, which translates to cheap. That is how and why
they are made.

When a write request is made to an IDE drive, the following occurs.
(1) The data for a single sector is written to a sector buffer.
(2) The head is switched to the correct one and the servo is told
to find the track.
(3) When the servo stabilizes over the correct track, the output
of the read amplifier is read, looking for sectors.
(4) When the correct sector is found, it is already too late.
(5) Therefore, the drive electronics has "remembered" the sector
(6) When the sector that is present just before the one you want to write,
is detected, (which is not the number before it because of interleave)
the drive starts counting clocks.
(7) It begins a write just as the sector you are going to overwrite comes
under the head. This is repeated for every sector to be written.

If you can keep this write sequence going, by caching writes in
software, you can improve performance over random reads and writes.

The sequence for reads is easier because you don't have to write-
splice. Instead:

(1) When correct sector is found, it is already in the sector
buffer, It is transfered out of the drive. In the meantime, the
disc is still spinning so you would be reading past the next
sector you want to transfer if it was not for interleave.
(2) The next sector is read, which because of interleave should
be the next sequential one.
(3) The sequence continues.

Typical cheap IDE drives have 3:1 interleave. Drives that can do DMA
can get down to 2:1

Most all SCSI drives can do 1:1 because they can queue multiple
commands, have internal caches, and a high I/O bandwidth.

> >
> > 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
> IBM is good enough to tell me that there are 8 zones on my platters, numbered
> 0 to 7 from the outside in. They also tell me the recording density at both
> ends. From that we can work out a rough estimate of the number of sectors per
> track and the number of tracks in a zone. If two requests are to different
> tracks, then which is performed before the other is largely irrelevant, so I
> can order my requests to minimize the total number of seeks.

Good luck. This means that the drive was so poorly designed that they
had to use 8 different sector interleaves to get acceptible performance.

> > 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.
> Yes, but my machine is almost always waiting for disk I/O. The only time my
> CPU utilization goes over 90% is when I'm running gcc. Usually my idle time is
> what is over 90%.

Guess again. CPU cycles used doing nothing useful are lost forever.
Getting a lucky hit on a sector boundary occasionally will never show
up as an average increase in I/O speed. It is way below the noise.

> The real argument against doing all this is that it will save at most one seek
> per two requests, which is only 5% timewise. Probably not worth all the effort.

The real argument against this is called "IDE". If you sorted reads
and writes (scatter/gather) for SCSI devices, you could accomplish

Dick Johnson
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.169 / U:0.016 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site