On Thu, Aug 03, 2017 at 05:33:13PM +0000, Bart Van Assche wrote:

On Thu, 2017-08-03 at 11:13 +0800, Ming Lei wrote:

quoted

On Thu, Aug 03, 2017 at 01:35:29AM +0000, Bart Van Assche wrote:

quoted

On Wed, 2017-08-02 at 11:31 +0800, Ming Lei wrote:

quoted

On Tue, Aug 01, 2017 at 03:11:42PM +0000, Bart Van Assche wrote:

quoted

On Tue, 2017-08-01 at 18:50 +0800, Ming Lei wrote:

quoted

On Tue, Aug 01, 2017 at 06:17:18PM +0800, Ming Lei wrote:

quoted

How can we get the accurate 'number of requests in progress' efficiently?

Hello Ming,

How about counting the number of bits that have been set in the tag set?
I am aware that these bits can be set and/or cleared concurrently with the
dispatch code but that count is probably a good starting point.

It has to be atomic_t, which is too too heavy for us, please see the report:

	http://marc.info/?t=149868448400003&r=1&w=2

Both Jens and I want to kill hd_struct.in_flight, but looks still no
good way. 

Hello Ming,

Sorry but I disagree that a new atomic variable should be added to keep track
of the number of busy requests. Counting the number of bits that are set in
the tag set should be good enough in this context.

That won't work because the tag set is host wide and shared by all LUNs.

Hello Ming,

Are you aware that the SCSI core already keeps track of the number of busy requests
per LUN? See also the device_busy member of struct scsi_device. How about giving the
block layer core access in some way to that counter?

Yes, I know that.

Last time I mentioned it to Christoph that this counter can be used for
implementing Runtime PM for avoiding to introduce one new counter to 
account pending I/O.

But for this purpose(estimating how many requests to dequeue from hctxs),
it isn't a good idea:

1) strictly speaking, atomic counter isn't enough, and lock 
is needed, because we need to make sure that the counter can't
be changed during dequeuing requests, so exporting the counter
to block won't work

2) even though you may think it is just for estimating, and
not use a lock, it isn't good too, because for some SCSI devices,
q->queue_depth is very small, both qla2xxx and lfpc's .cmd_perf_lun
is 3. So it can be very inaccurate since it is normal to dequeue
requests from all hctx at the same time.

Also I have posted V2 today, from the test result on SRP, looks
it is good to dequeue one request one time, so I suggest that we
follow mq scheduler's way to dequeue request(pick up one in one time)
for blk-mq 'none' in this patchset. We may consider to improve
it in future if there is better & mature idea.


Thanks,
Ming