On 2019/11/18 9:47, Ming Lei wrote: > Hi Damine, > > On Mon, Nov 18, 2019 at 12:18:48AM +0000, Damien Le Moal wrote: >> On 2019/11/17 17:08, Ming Lei wrote: >>> Now the requeue queue is run in scsi_end_request() unconditionally if both >>> target queue and host queue is ready. We should have re-run request queue >>> only after this device queue becomes busy for restarting this LUN only. >>> >>> Recently Long Li reported that cost of run queue may be very heavy in >>> case of high queue depth. So improve this situation by only running >>> requesut queue when this LUN is busy. >> >> s/requesut/request >> >> Also, shouldn't this patch have the tag: >> >> Reported-by: Long Li <longli@xxxxxxxxxxxxx> >> >> ? > > Will do that in V2. > >> >> Another remark is that Long's approach is generic to the block layer >> while your patch here is scsi specific. I wonder if the same problem >> cannot happen with other drivers too ? > > Not sure what you meant about the same problem. > > It is definitely bad to unconditionally call blk_mq_run_hw_queues() > in driver's IO completion handler from performance viewpoint. > > This patch simply addresses this SCSI specific issue, since blk_mq_run_hw_queues() > shouldn't be called from scsi_end_request() when the device queue isn't busy. > > If other driver has such kind of issue, I believe it should have been fixed in > driver too. > > So my patch isn't contradictory with Long's patch which improves generic blk-mq's > run queue. OK. Thanks. > > Thanks, > Ming > > -- Damien Le Moal Western Digital Research
