|
|
These guidelines can greatly enhance the performance of your HBA driver and of the system in general.
Scheduling disk jobs means choosing an order in which to process disk jobs. Requests are sent down from target drivers to HBA drivers on a first-come/first-served basis. Drivers that do not sort the jobs to reduce seek (and possibly latency) time risk sluggish performance, particularly as the work load grows.
There are many disk scheduling policies; a simple shortest-seek first algorithm works well for many drivers and disks. Because jobs can be starved (that is, receive insufficient processing attention) using this heuristic, you may want to use an amended shortest-seek first. One simple way to prevent starvation is to put jobs on the back of a queue as they come in. If a job is at the head of a queue beyond a fixed amount of time, the job is processed regardless of the position of the disk head.
A variation of this scheme is to move the disk head toward the starving job, picking up other jobs on the way. In either case, after the starving job is serviced, the driver would resume the shortest-seek first policy.
HBA controllers can frequently handle sixty-four or more jobs at a time, but this does not imply that it can perform optimally with so many jobs. In particular, when scheduling disk requests, it helps to keep jobs in the driver so that the scheduler has more jobs from which to choose. You should experiment with your HBA driver and hardware to determine the optimum number of jobs to send concurrently.
Also keep in mind that multiple disks may be connected to the same controller; this is often the case with SCSI controllers. In this case, try to keep all disks busy instead of flooding the controller with jobs for a single target.
Other things being equal, using less memory is always better than using more memory. Tests have shown that kernel size, and hence driver size, is one of the most critical performance issues. In particular, startup and shutdown routines should be kept small, and the driver should free buffers when it can.
When building a driver for a multiprocessing system, access to shared resources may become a performance issue. To reduce the locking impact, obtain locks only when necessary and hold them for the minimum time possible.
In some cases, it helps to split resources into multiple pools. For example, for a structure that is frequently locked, it may pay to add a second lock to synchronize some of the fields while the first lock synchronizes other fields. Similarly, consider having two lists of freed objects instead of just one; if the two lists are accessed randomly, resource contention for the list will have been halved.