![]() | |||||||||||||
Messages in this thread |
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
| ||||||||||||
| Last update: 2005-05-27 08:30 [from the cache] ©2003-2008 | |||||||||||||