On 11/12/2016 06:32 PM, Christoph Hellwig wrote:
On Fri, Nov 11, 2016 at 07:22:05PM +0100, Hannes Reinecke wrote:
Well, it's the same as with megasas and mpt3sas. Each of those have
a single MMIO register where the driver writes the address of the
command into. What exactly the hardware does in the back doesn't
really matter here; the command is in memory and the hardware can
access it as it sees fit. So from that point of view we can assume
having a submission queue to match the completion queue;
With that setup we do have a contention point on the single command
register, but that's about it.
We still should benefit from scsi-mq, though.
How do we benefit from scsi-mq in this case? We still hit global
cachelines like commands_outstanding in the driver, and we lost the
batching done by the ctx -> hw_ctx layering for the single queue
blk-mq case. We also get much less efficient merging and will not
have the chance of having and I/O schedule in the near future.
One day to mark with bright red in the calendar.
Christoph Hellwig is telling me _NOT_ to use scsi-mq.
> But back to my question from the last mail: What workload is improved
> by using this patch?
>
This patch was done so see what would needed to be done to convert a
legacy driver.
As I was under the impression that scsi-mq is the way forward, seeing
that it should be enabled per default.
But I must have been mistaken. Apparently.
Slightly confused,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
