SATA NCQ support

Update the patch, it's against bleeding edge git (applies to 2.6.12-rc5 as well). Changes:

drivers/scsi/libata-core.c (mode:100644) +6 -0

@@ -2868,6 +2995,21 @@
 int ata_qc_issue(struct ata_queued_cmd *qc)
 {
 	struct ata_port *ap = qc->ap;
+	int rc = ATA_QC_ISSUE_FATAL;
+
+	/*
+	 * see if we can queue one more command at this point in time, see
+	 * comment at ata_qc_issue_ok(). NCQ commands typically originate from
+	 * the SCSI layer, we can ask the mid layer to defer those commands

drivers/scsi/libata-scsi.c (mode:100644) +16 -0

@@ -353,6 +354,13 @@
 			 */
 			blk_queue_max_sectors(sdev->request_queue, 2048);
 		}
+
+		if (dev->flags & ATA_DFLAG_NCQ) {
+			int ddepth = ata_id_queue_depth(dev->id);
+
+			depth = min(sdev->host->can_queue, ddepth);
+			scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG, depth);
+		}
 	}
 
 	return 0;	/* scsi layer doesn't check return value, sigh */

@@ -1594,3 +1641,22 @@
 	}
 }
 
+int ata_scsi_change_queue_depth(struct scsi_device *sdev, int queue_depth)
+{
+	struct ata_port *ap;
+	struct ata_device *dev;
+	int max_depth;
+
+	if (sdev->id >= ATA_MAX_DEVICES)
+		return sdev->queue_depth;
+

Quoted 2 lines · Jens Axboe

Update the patch, it's against bleeding edge git (applies to 2.6.12-rc5 as well). Changes:

I'll throw this into libata-dev branch "ncq" right now.

Quoted 5 lines

drivers/scsi/ahci.c (mode:100644) +5 -0

+static void ahci_host_ncq_intr_err(struct ata_port *ap)
+{
+	void *mmio = ap->host_set->mmio_base;
+	void *port_mmio = ahci_port_base(mmio, ap->port_no);
+	char *buffer;

drivers/scsi/ahci.c (mode:100644) line 631

Quoted 6 lines

drivers/scsi/ahci.c (mode:100644) +6 -0

+
+	printk(KERN_ERR "ata%u: ncq interrupt error\n", ap->id);
+
+	ahci_intr_error(ap, readl(port_mmio + PORT_IRQ_STAT));
+
+	buffer = kmalloc(512, GFP_KERNEL);

cannot use GFP_KERNEL in interrupt context

Quoted 11 lines

drivers/scsi/libata-core.c (mode:100644) +5 -0

@@ -2868,6 +2995,21 @@
 int ata_qc_issue(struct ata_queued_cmd *qc)
 {
 	struct ata_port *ap = qc->ap;
+	int rc = ATA_QC_ISSUE_FATAL;
+
+	/*
+	 * see if we can queue one more command at this point in time, see
+	 * comment at ata_qc_issue_ok(). NCQ commands typically originate 

from

drivers/scsi/libata-core.c (mode:100644) line 3012

Quoted 10 lines

drivers/scsi/libata-core.c (mode:100644) +10 -0

+	 * the SCSI layer, we can ask the mid layer to defer those commands
+	 * similar to a QUEUE_FULL condition on a 'real' SCSI device
+	 */
+	if (!ata_qc_issue_ok(ap, qc, 0)) {
+		if (qc->flags & ATA_QCFLAG_DEFER)
+			return ATA_QC_ISSUE_DEFER;
+
+		ata_qc_issue_wait(ap, qc);
+		assert(ata_qc_issue_ok(ap, qc, 0));
+	}

This is too late. We shouldn't get to this point and find out, "uh oh, queue full."

ata_qc_new() should fail to obtain a qc if the queue is full, at which point you may directly return queue-full.

If ata_qc_new() succeeds, but wish to wait for the queue to drain, add that logic -much- earlier than the ata_qc_issue() call. I would rather have that logic at a higher level.

Quoted 14 lines

drivers/scsi/libata-scsi.c (mode:100644) +14 -0

+int ata_scsi_change_queue_depth(struct scsi_device *sdev, int queue_depth)
+{
+	struct ata_port *ap;
+	struct ata_device *dev;
+	int max_depth;
+
+	if (sdev->id >= ATA_MAX_DEVICES)
+		return sdev->queue_depth;
+
+	ap = (struct ata_port *) &sdev->host->hostdata[0];
+	dev = &ap->device[sdev->id];
+
+	max_depth = min(sdev->host->can_queue, ata_id_queue_depth(dev->id));
+	if (queue_depth > max_depth)

drivers/scsi/libata-scsi.c (mode:100644) line 1662

Quoted 5 lines

drivers/scsi/libata-scsi.c (mode:100644) +5 -0

+		queue_depth = max_depth;
+
+	scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG, queue_depth);
+	return queue_depth;
+}

Please add this function immediately above, or below, ata_scsi_slave_config(). That will make backporting to 2.4.x easier.

Quoted 12 lines

===================================================================
--- 3ac9a34948049bff79a2b2ce49c0a3c84e35a748/include/linux/ata.h (mode:100644)
+++ uncommitted/include/linux/ata.h (mode:100644)

include/linux/ata.h (mode:100644) +0 -1

@@ -79,7 +79,8 @@
 	ATA_NIEN		= (1 << 1),	/* disable-irq flag */
 	ATA_LBA			= (1 << 6),	/* LBA28 selector */
 	ATA_DEV1		= (1 << 4),	/* Select Device 1 (slave) */
-	ATA_DEVICE_OBS		= (1 << 7) | (1 << 5), /* obs bits in dev 

reg */

include/linux/ata.h (mode:100644) +2 -0

+	ATA_DEVICE_OBS		= (1 << 5), 	/* obs bits in dev reg */
+	ATA_FPDMA_FUA		= (1 << 7),	/* FUA cache bypass bit */

Quoted 4 lines

	ATA_DEVCTL_OBS		= (1 << 3),	/* obsolete bit in devctl 
	reg */
	ATA_BUSY		= (1 << 7),	/* BSY status bit */
	ATA_DRDY		= (1 << 6),	/* device ready */

Don't do this. You can add ATA_FPDMA_FUA, but don't arbitrarily change ATA_DEVICE_OBS.

This is something that may have to be done on a per-device basis.

That is the typical case, ata_qc_new() succeeds but we cannot issue the command yet. So where do you want this logic placed? You cannot drop the host_lock in-between, as that could potentially change the situation.

Quoted 3 lines · Jens Axboe

That is the typical case, ata_qc_new() succeeds but we cannot issue the command yet. So where do you want this logic placed? You cannot drop the host_lock in-between, as that could potentially change the situation.

ata_scsi_translate() in libata-scsi.c, in between the call to ata_scsi_qc_new() and ata_qc_issue().

something like:

	if (ata_scsi_qc_new() fails ||
	    (depth > 0 && ata_check_non_ncq_cmd()))
		complete SCSI command with 'queue full'

NOTE!

I just noticed a bug -- When ata_scsi_qc_new() fails, the code should complete the command with queue-full, but does not.

        qc = ata_scsi_qc_new(ap, dev, cmd, done);
        if (!qc)
                return;

Quoted 10 lines · Jeff Garzik

Quoted 3 lines · Jens Axboe

That is the typical case, ata_qc_new() succeeds but we cannot issue the command yet. So where do you want this logic placed? You cannot drop the host_lock in-between, as that could potentially change the situation.

ata_scsi_translate() in libata-scsi.c, in between the call to ata_scsi_qc_new() and ata_qc_issue().

something like:

Quoted 3 lines

	if (ata_scsi_qc_new() fails ||
	    (depth > 0 && ata_check_non_ncq_cmd()))
		complete SCSI command with 'queue full'

That is an improvement for SCSI originated commands, I can drop ATA_QCFLAG_DEFER then. Will make that change. But what about ata_qc_issue() from other places? That is the ugly code, which will hit the waiting currently.

Actually, slight "problem" there as well... We need to translate the SCSI command prior to making this decision, as we may get both NCQ and non-NCQ commands from that path as well. For now I'll just make the distinction that fs based SCSI requests are the only NCQ candidates, ok?

Quoted 5 lines · Jeff Garzik

I just noticed a bug -- When ata_scsi_qc_new() fails, the code should complete the command with queue-full, but does not.

       qc = ata_scsi_qc_new(ap, dev, cmd, done);
       if (!qc)
               return;

Indeed, looks like an old bug.

Quoted 9 lines · Jens Axboe

Quoted 6 lines · Jeff Garzik

I just noticed a bug -- When ata_scsi_qc_new() fails, the code should complete the command with queue-full, but does not.

      qc = ata_scsi_qc_new(ap, dev, cmd, done);
      if (!qc)
              return;

Quoted 1 line

Indeed, looks like an old bug.

Yep. If you are knocking around in that area, would you mind killing it for me? :)

Actually, I didn't look far enough up - ata_scsi_qc_new() already completes the command with QUEUE_FULL if ata_qc_new_init() fails. So there's no bug, but perhaps it would be cleaner to move it to ata_scsi_translate instead?

Quoted 4 lines · Jens Axboe

Actually, I didn't look far enough up - ata_scsi_qc_new() already completes the command with QUEUE_FULL if ata_qc_new_init() fails. So there's no bug, but perhaps it would be cleaner to move it to ata_scsi_translate instead?

Ah, ok.

Yes, if you are in a cleaning mood, that would be a better location.

Quoted 7 lines · Jeff Garzik

Quoted 4 lines · Jens Axboe

Actually, I didn't look far enough up - ata_scsi_qc_new() already completes the command with QUEUE_FULL if ata_qc_new_init() fails. So there's no bug, but perhaps it would be cleaner to move it to ata_scsi_translate instead?

Quoted 3 lines

Ah, ok.

Yes, if you are in a cleaning mood, that would be a better location.

Always in a code cleaning mood - here it is against vanilla, I've integrated it in the ncq stuff as well.

Update the patch, it's against bleeding edge git (applies to 2.6.12-rc5 as well). Changes:

- (libata) Change to SCSI change_queue_depth API, kill current hack.

- (ahci) Move SActive bit set to ahci_qc_issue() where it belongs.

Quoted 3 lines · Jens Axboe

Update the patch, it's against bleeding edge git (applies to 2.6.12-rc5 as well). Changes:

Quoted 3 lines

- (libata) Change to SCSI change_queue_depth API, kill current hack.

- (ahci) Move SActive bit set to ahci_qc_issue() where it belongs.

OK, so this is for AHCI. What are the options for people whose mainboards aren't blessed with AHCI, but use for instance VIA or older Promise chips? Buy new hardware? Or wait until someone comes up with an implementation?

Can this queueing be emulated by software (libata or the libata chipset driver) or would such be mentioned in Jeff's list as "host-based queueing"?

NCQ requires hardware support from both the controller and hard drive, you can view Jeff's libata status page for which controllers support NCQ.

Quoted 3 lines · Jens Axboe

NCQ requires hardware support from both the controller and hard drive, you can view Jeff's libata status page for which controllers support NCQ.

So that means controllers that do not support either NCQ or HBQ just

suck and should not be cared about, and if I were to go into SATA, I should just get a new controller and forget about my onboard VIA crap. (I read newer VIA are supposed to support AHCI which is good.)

Quoted 3 lines

suck and should not be cared about, and if I were to go into SATA, I should just get a new controller and forget about my onboard VIA crap. (I read newer VIA are supposed to support AHCI which is good.)

SATA is still pretty fast without NCQ, it just makes some operations a

lot faster. But of course if you want the best, you would opt for some setup that allows NCQ.

People have lived happily without NCQ support in SATA for years, I'm sure you could too :-)

Quoted 4 lines · Jens Axboe

Quoted 3 lines

suck and should not be cared about, and if I were to go into SATA, I should just get a new controller and forget about my onboard VIA crap. (I read newer VIA are supposed to support AHCI which is good.)

Quoted 1 line

SATA is still pretty fast without NCQ, it just makes some operations a

Do I take this as SATA is faster than legacy ATA? In what respect? UDMA/33 and SATA I shouldn't be much different if I use the same drive, or is there something?

Quoted 3 lines · Matthias Andree

Do I take this as SATA is faster than legacy ATA? In what respect? UDMA/33 and SATA I shouldn't be much different if I use the same drive, or is there something?

It is "likely" to be faster. Faster bus, newer technology.

Jeff

SATA is still pretty fast without NCQ,

People have lived happily without NCQ support in SATA for years, I'm sure you could too :-)

I would be interested to see those benchmarks people were posting earlier claiming 30-40% difference retested with write caching disabled. I suspect disabling write caching will demolish the non-NCQ performance but have a much smaller effect on NCQ-enabled performance.

Currently Postgres strongly recommends SCSI drives and the belief is that it's the tagged command queuing that allows SCSI drives to perform well without resorting to data integrity destroying write caching.

If used properly, I don't feel write cache "destroys" data integrity, you just need to get your power failure tolerance elsewhere.

ATA has a limitation of 32 tags, so queued write cache off won't beat unqueued write cache on in any modern drive.

The real reason most SCSI drives do so well uncached is they use huge magnets with short, stiff actuators, smaller platters, and they spin significantly faster. NCQ certainly helps, but spending more money on mechanics makes a significant difference. Pick up a SCSI drive and an ATA drive, you'll feel the SCSI weighs seemingly twice as much.

Quoted 2 lines

ATA has a limitation of 32 tags, so queued write cache off won't beat unqueued write cache on in any modern drive.

People earlier were quoting 30-40% gains with NCQ enabled. I assumed those were with the same drive in otherwise the same configuration, presumably with write-caching enabled.

Without any form of command queueing write-caching imposes a severe performance loss, the question is how much of that loss is erased when NCQ is present.

People actually tend to report that IDE drives are *faster*. Until they're told they have to disable write-caching on their IDE drives to get a fair comparison, then the performance is absolutely abysmal. The interesting thing is that SCSI drives don't seem to take much of a performance hit from having write-caching disabled while IDE drives do.

Quoted 6 lines

People actually tend to report that IDE drives are *faster*. Until they're told they have to disable write-caching on their IDE drives to get a fair comparison, then the performance is absolutely abysmal. The interesting thing is that SCSI drives don't seem to take much of a performance hit from having write-caching disabled while IDE drives do.

NCQ will surely lessen the impact of disabling write caching, how much still remains to be seen. You could test, if you have the hardware :) Real life testing is more interesting than benchmarks.

Quoted 10 lines · Jens Axboe

Quoted 6 lines

People actually tend to report that IDE drives are *faster*. Until they're told they have to disable write-caching on their IDE drives to get a fair comparison, then the performance is absolutely abysmal. The interesting thing is that SCSI drives don't seem to take much of a performance hit from having write-caching disabled while IDE drives do.

NCQ will surely lessen the impact of disabling write caching, how much still remains to be seen. You could test, if you have the hardware :) Real life testing is more interesting than benchmarks.

With a few simple tests, I'm unable to show any write performance improvement with write back caching off and NCQ (NCQ with queueing depth of 1 and 16 tested). I get a steady 0.55-0.57MiB/sec with 8 threads random writes, a little over 5MiB/sec with sequential writes.

Reads are _much_ nicer. Sequential read with 8 threads are 23% faster with a queueing depth of 16 than 1, random reads are 85% (!!) faster at depth 16 than 1.

Testing was done with the noop io scheduler this time, to only show NCQ benefits outside of what the io scheduler can do for reordering.

This is with a Maxtor 7B300S0 drive. I would have posted results for a Seagate ST3120827AS as well, but that drive happily ignores any attempt to turn off write back caching. To top things off, it even accepts FUA writes but ignores that as well (they still go to cache).

Quoted 21 lines · Jens Axboe

Quoted 10 lines · Jens Axboe

Quoted 6 lines

People actually tend to report that IDE drives are *faster*. Until they're told they have to disable write-caching on their IDE drives to get a fair comparison, then the performance is absolutely abysmal. The interesting thing is that SCSI drives don't seem to take much of a performance hit from having write-caching disabled while IDE drives do.

NCQ will surely lessen the impact of disabling write caching, how much still remains to be seen. You could test, if you have the hardware :) Real life testing is more interesting than benchmarks.

With a few simple tests, I'm unable to show any write performance improvement with write back caching off and NCQ (NCQ with queueing depth of 1 and 16 tested). I get a steady 0.55-0.57MiB/sec with 8 threads random writes, a little over 5MiB/sec with sequential writes.

Reads are _much_ nicer. Sequential read with 8 threads are 23% faster with a queueing depth of 16 than 1, random reads are 85% (!!) faster at depth 16 than 1.

Quoted 7 lines

Testing was done with the noop io scheduler this time, to only show NCQ benefits outside of what the io scheduler can do for reordering.

This is with a Maxtor 7B300S0 drive. I would have posted results for a Seagate ST3120827AS as well, but that drive happily ignores any attempt to turn off write back caching. To top things off, it even accepts FUA writes but ignores that as well (they still go to cache).

Actually, I partly take that back. The Seagate _does_ honor drive write back caching disable and it does show a nice improvement with NCQ for that case. Results are as follows:

8 thread io case, 4kb block size, noop io scheduler, ST3120827AS.

Write cache off:

                Depth 1         Depth 30        Diff
Seq read:       18.94           21.51           +  14%
Ran read:        0.86            1.24           +  44%
Seq write:       6.58           19.30           + 193%
Ran write:       1.00            1.27           +  27%

Write cache on:

                Depth 1         Depth 30        Diff
Seq read:       18.78           21.58           +  15%
Ran read:        0.84            1.20           +  43%
Seq write:      24.49           23.26           -   5%
Ran write:       1.55            1.63           +   5%

Huge benefit on writes with NCQ when write back caching is off, with it on I think the deviation is within standard jitter of this benchmark.

OK, so this is for AHCI. What are the options for people whose mainboards aren't blessed with AHCI, but use for instance VIA or older Promise chips? Buy new hardware? Or wait until someone comes up with an implementation?