On Thu, May 26 2005, Mark Lord wrote:

I also saw a good boost from NCQ on the qstor driver (full version,
not the libata subset) last year.  Very good for busy servers
and RAID arrays.

It does seem to work amazingly well, from a performance point of view.

Jens Axboe wrote:
+	do {
+		/*
+		 * we rely on the FIFO order of the exclusive waitqueues
+		 */
+		prepare_to_wait_exclusive(&ap->cmd_wait_queue, &wait,
+					  TASK_UNINTERRUPTIBLE);
+
+		if (!ata_qc_issue_ok(ap, qc, 1)) {
+			spin_unlock_irq(&ap->host_set->lock);
+			schedule();
+			spin_lock_irq(&ap->host_set->lock);
+		}
+
+		finish_wait(&ap->cmd_wait_queue, &wait);
+
+	} while (!ata_qc_issue_ok(ap, qc, 1));

In this bit (above), is it possible for this code to ever
be invoked from a SCHED_RR or SCHED_FIFO context?

If so, it will lock out all lower-priority processes
for the duration of the polling interval.

Yeah, I'm not a huge fan of the need for the above code... If every qc
was tied to a SCSI command, we could just ask for a later requeue of the
request as is currently done with NCQ commands. Alternatively, we could
add an internal libata qc queue for postponing these commands. That
would take a little effort, as the sync errors reported by
ata_qc_issue() would then be need to signalled async through the
completion callback instead.

Jeff, what do you think?

-- 
Jens Axboe