On Thu, 2017-07-13 at 18:43 +0800, Ming Lei wrote:

On Wed, Jul 12, 2017 at 03:39:14PM +0000, Bart Van Assche wrote:

quoted

On Wed, 2017-07-12 at 10:30 +0800, Ming Lei wrote:

quoted

On Tue, Jul 11, 2017 at 12:25:16PM -0600, Jens Axboe wrote:

quoted

What happens with fluid congestion boundaries, with shared tags?

=20
The approach in this patch should work, but the threshold may not
be accurate in this way, one simple method is to use the average
tag weight in EWMA, like this:
=20
	sbitmap_weight() / hctx->tags->active_queues

=20
Hello Ming,
=20
That approach would result in a severe performance degradation. "active=

_queues"

quoted

namely represents the number of queues against which I/O ever has been =

queued.

quoted

If e.g. 64 LUNs would be associated with a single SCSI host and all 64 =

LUNs are

quoted

responding and if the queue depth would also be 64 then the approach yo=

u

quoted

proposed will reduce the effective queue depth per LUN from 64 to 1.

=20
No, this approach does _not_ reduce the effective queue depth, it only
stops the queue for a while when the queue is busy enough.

In this case, there may not have congestion because for blk-mq at most al=

lows

to assign queue_depth/active_queues tags to each LUN, please see hctx_may=

_queue().

Hello Ming,

hctx_may_queue() severely limits the queue depth if many LUNs are associate=
d
with the same SCSI host. I think that this is a performance regression
compared to scsi-sq and that this performance regression should be fixed.

Bart.=