Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Wed, Oct 11, 2017 at 07:56:04PM -0000, Michael van Elst wrote:
> tls%panix.com@localhost (Thor Lancelot Simon) writes:
> 
> >It probably has to do with our small maximum transfer size.  The disk is
> >probably trying to be safer and *not* caching tagged writes as aggressively,
> >but with only 32 commands in-flight (SCSI/SAS allow 256) and a maximum
> >transfer size of 64K (our MAXPHYS), that's only 2MB of in-flight data;
> >maybe not enough to keep up with the actual bandwidth of the media at
> >its real latency.
> 
> With a larger MAXPHYS there wouldn't be as many transfers in flight.

That depends on the workload and the clustering behavior of the filesystem.

Remember, in the relevant sense, data the disk has already accepted is
"in flight" from the point of view of absorbing latency, in the non-NCQ,
write-cache-enabled case.  The host can't tell it's "in flight", but it
still is -- so the host will continue to write aggressively even if the
filesystem's clustering behavior would otherwise throttle it -- because
to the host, these writes appear to be "complete".

If the drive is not aggressively caching writes in the same way when NCQ
is in use, this won't happen, since less writes will appear, to the host,
to be completed.  With only 32 tags available, we may need a larger
transfer per tag to allow the same amount of in-flight data (if the disk,
with NCQ enabled, has stopped lying about whether the transfers are
really complete).

-- 
  Thor Lancelot Simon	                                     tls%panix.com@localhost
 "The two most common variations translate as follows:
	illegitimi non carborundum = the unlawful are not silicon carbide
	illegitimis non carborundum = the unlawful don't have silicon carbide."