Re: [PATCH V3] blk-mq: introduce BLK_STS_DEV_RESOURCE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2018-01-27 at 14:09 -0500, Mike Snitzer wrote:
> Ming let me know that he successfully tested this V3 patch using both
> your test (fio to both mpath and underlying path) and Bart's (02-mq with
> can_queue in guest).
> 
> Would be great if you'd review and verify this fix works for you too.
> 
> Ideally we'd get a fix for this regression staged for 4.16 inclusion.
> This V3 patch seems like the best option we have at this point.

Hello Mike,

There are several issues with the patch at the start of this thread:
- It is an unnecessary change of the block layer API. Queue stalls can
  already be addressed with the current block layer API, namely by inserting
  a blk_mq_delay_run_hw_queue() call before returning BLK_STS_RESOURCE.
- The patch at the start of this thread complicates code further that is
  already too complicated, namely the blk-mq core.
- The patch at the start of this thread introduces a regression in the
  SCSI core, namely a queue stall if a request completion occurs concurrently
  with the newly added BLK_MQ_S_SCHED_RESTART test in the blk-mq core.

As a kernel maintainer one of your responsibilities is to help keeping the
quality of the kernel code high. So I think that you, as a kernel maintainer,
should tell Ming to discard this patch instead of
asking to merge it upstream
given all the disadvantages of this patch.

Bart.




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux