From: drew@kinglear.cs.colorado.edu (Drew Eckhardt) Subject: Re: SCSI Performance (Yet Again) Date: Fri, 27 Aug 1993 00:20:40 GMT
In article <1993Aug25.181139.17869@swan.pyr> iiitac@swan.pyr (Alan Cox) writes:
>
>Before people go berserk with wild optimizations the Linux driver doesn't
>handle two optimizations it could (at least if it does then Linus has
>cleverly concealed it 8-))
>
>1. Rotational optimization. Given that the rotational latency of a
> good disk these days is no longer irrelevant compared with the
> seek time this would be a good idea.
You could do some playing arround in the filesystem code, so that
successive "cylinders" were skewed with respect to each other to
accomodate the track-to-track seek time, however you need some sort
of hooks into the lowlevel drivers to find out the geometry of the
disk - with SCSI-II , you get the NOTCH pages for ZBR drives, for
anything SCSI-I CCS or later you get the RIGID DISK GEOMETRY and
FORMAT mode pages, in any case these things pages can lie.
So, this isn't entirely a SCSI problem, more a of a block device
driver to file system communication thing.
Rotational optomization at the SCSI driver level alone is for
all practical purposes impossible. You have no idea what the
current position is of the disk, you can't be sure of the time it's
going to take to establish a nexus for the new command, and don't
know what sort of readahead the disk has done.
>2. Request merging - Multiple requests can be merged into one
> disk operation. This should enable better use to be made of the
> DMA potentially.
This is allready done. Multiple requests for contiguous sectors are
merged as long as the old request is for fewer than 254 sectors.
-- Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Condemn Colorado for Amendment Two. | Drew Eckhardt Use Linux, the fast, flexible, and free 386 unix | drew@cs.Colorado.EDU Will administer Unix for food |