Re: [PATCH V7 2/2] scsi: Align block queue to dma_get_cache_alignment()

Hi Huacai, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc2 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] scsi: esas2r: make bin_attr_default_nvram const

Make this const as it is only passed to the const arguments of the functions sysfs_remove_bin_file and sysfs_create_bin_file. Make the declaration const too. Structure found using Coccinelle and changes done by hand. Signed-off-by: Bhumika Goyal ---

Re: [PATCH V5 00/14] blk-mq-sched: improve sequential I/O performance(part 1)

On Sat, Sep 30, 2017 at 06:27:13PM +0800, Ming Lei wrote: > Hi Jens, > > In Red Hat internal storage test wrt. blk-mq scheduler, we > found that I/O performance is much bad with mq-deadline, especially > about sequential I/O on some multi-queue SCSI devcies(lpfc, qla2xxx, > SRP...) > > Turns out

[PATCH V5 7/7] blk-mq-sched: don't dequeue request until all in ->dispatch are flushed

During dispatching, we moved all requests from hctx->dispatch to one temporary list, then dispatch them one by one from this list. Unfortunately during this period, run queue from other contexts may think the queue is idle, then start to dequeue from sw/scheduler queue and still try to dispatch

[PATCH V5 4/7] blk-mq: introduce blk_mq_dequeue_from_ctx()

This function is introduced for dequeuing request from sw queue so that we can dispatch it in scheduler's way. More importantly, some SCSI devices may set q->queue_depth, which is a per-request_queue limit, and applied on pending I/O from all hctxs. This function is introduced for avoiding to

[PATCH V5 5/7] blk-mq-sched: move actual dispatching into one helper

So that it becomes easy to support to dispatch from sw queue in the following patch. No functional change. Reviewed-by: Bart Van Assche Reviewed-by: Omar Sandoval Tested-by: Oleksandr Natalenko Tested-by: Tom Nguyen

[PATCH V5 6/7] blk-mq-sched: improve dispatching from sw queue

SCSI devices use host-wide tagset, and the shared driver tag space is often quite big. Meantime there is also queue depth for each lun(.cmd_per_lun), which is often small. So lots of requests may stay in sw queue, and we always flush all belonging to same hw queue and dispatch them all to driver,

[PATCH V5 1/7] blk-mq: issue rq directly in blk_mq_request_bypass_insert()

With issuing rq directly in blk_mq_request_bypass_insert(), we can: 1) avoid to acquire hctx->lock. 2) the dispatch result can be returned to dm-rq, so that dm-rq can use this information for improving I/O performance, and part2 of this patchset will do that. 3) Also the following patch for

[PATCH V5 3/7] sbitmap: introduce __sbitmap_for_each_set()

We need to iterate ctx starting from any ctx in round robin way, so introduce this helper. Cc: Omar Sandoval Tested-by: Oleksandr Natalenko Tested-by: Tom Nguyen Tested-by: Paolo Valente Signed-off-by:

[PATCH V5 00/14] blk-mq-sched: improve sequential I/O performance(part 1)

Hi Jens, In Red Hat internal storage test wrt. blk-mq scheduler, we found that I/O performance is much bad with mq-deadline, especially about sequential I/O on some multi-queue SCSI devcies(lpfc, qla2xxx, SRP...) Turns out one big issue causes the performance regression: requests are still

[PATCH V5 2/7] blk-mq-sched: fix scheduler bad performance

When hw queue is busy, we shouldn't take requests from scheduler queue any more, otherwise it is difficult to do IO merge. This patch fixes the awful IO performance on some SCSI devices(lpfc, qla2xxx, ...) when mq-deadline/kyber is used by not taking requests if hw queue is busy. Tested-by:

Re: [PATCH V7 0/6] block/scsi: safe SCSI quiescing

Hi Martin, On Sat, Sep 30, 2017 at 11:47:10AM +0200, Martin Steigerwald wrote: > Hi Ming. > > Ming Lei - 30.09.17, 14:12: > > Please consider this patchset for V4.15, and it fixes one > > kind of long-term I/O hang issue in either block legacy path > > or blk-mq. > > > > The current SCSI quiesce

Re: [PATCH V7 0/6] block/scsi: safe SCSI quiescing

Hi Ming. Ming Lei - 30.09.17, 14:12: > Please consider this patchset for V4.15, and it fixes one > kind of long-term I/O hang issue in either block legacy path > or blk-mq. > > The current SCSI quiesce isn't safe and easy to trigger I/O deadlock. Isn´t that material for -stable as well? I´d

[GIT PULL] SCSI fixes for 4.14-rc2

Eight mostly minor fixes for recently discovered issues in drivers. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes The short changelog is: Dave Carroll (1): scsi: aacraid: Fix 2T+ drives on SmartIOC-2000 Guilherme G. Piccoli (1):

Re: [PATCH] scsi: ufs: Make use of UFS_BIT macro wherever possible

Hi Martin, On 09/26/2017 01:01 AM, Martin K. Petersen wrote: > > Alim, > >> Should I drop this patch and send another one which removes UFS_BIT() >> macro? > > I fail to see the point of UFS_BIT(). So yes. > > Please make sure to CC: Subhash on ufs changes. > Thanks for looking into this

[PATCH 1/3] scsi: ufs: Change HCI marco to actual bit position

Currently UFS HCI uses UFS_BIT() macro to get various bit position for the hardware registers status bits. Which makes code longer instead of shorter. This macro does not improve code readability as well. Lets re-write these macro definition with the actual bit position. Suggested-by: Bart Van

[PATCH 3/3] scsi: ufs: Remove unused UFS_BIT() macro

Since we have coverted all the user of UFS_BIT() macro with the actual bit position, let remove unused UFS_BIT()macro. Signed-off-by: Alim Akhtar --- drivers/scsi/ufs/ufshci.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshci.h

[PATCH 2/3] scsi: ufs-qcom: Remove uses of UFS_BIT() macro

Use actaul bit position instead of UFS_BIT() macro. This patch also changes bit-17 to meaningful #define. This change is as per discussion here [1] [1] -> https://lkml.org/lkml/2017/8/28/786 Signed-off-by: Alim Akhtar Cc: Subhash Jadavani ---

[PATCH V7 1/6] blk-mq: only run hw queues for blk-mq

This patch just makes it explicitely. Tested-by: Oleksandr Natalenko Tested-by: Martin Steigerwald Reviewed-by: Johannes Thumshirn Cc: Bart Van Assche Signed-off-by: Ming Lei ---

[PATCH V7 4/6] block: prepare for passing RQF_PREEMPT to request allocation

REQF_PREEMPT is a bit special because the request is required to be dispatched to lld even when SCSI device is quiesced. So this patch introduces __blk_get_request() and allows users to pass RQF_PREEMPT flag in, then we can allow to allocate request of RQF_PREEMPT when queue is in mode of PREEMPT

[PATCH V7 6/6] SCSI: set block queue at preempt only when SCSI device is put into quiesce

Simply quiesing SCSI device and waiting for completeion of IO dispatched to SCSI queue isn't safe, it is easy to use up request pool because all allocated requests before can't be dispatched when device is put in QIUESCE. Then no request can be allocated for RQF_PREEMPT, and system may hang

[PATCH V7 5/6] block: support PREEMPT_ONLY

When queue is in PREEMPT_ONLY mode, only RQF_PREEMPT request can be allocated and dispatched, other requests won't be allowed to enter I/O path. This is useful for supporting safe SCSI quiesce. Part of this patch is from Bart's '[PATCH v4 4∕7] block: Add the QUEUE_FLAG_PREEMPT_ONLY request

[PATCH V7 2/6] block: tracking request allocation with q_usage_counter

This usage is basically same with blk-mq, so that we can support to freeze legacy queue easily. Also 'wake_up_all(>mq_freeze_wq)' has to be moved into blk_set_queue_dying() since both legacy and blk-mq may wait on the wait queue of .mq_freeze_wq. Tested-by: Oleksandr Natalenko

[PATCH V7 0/6] block/scsi: safe SCSI quiescing

Hi Jens, Please consider this patchset for V4.15, and it fixes one kind of long-term I/O hang issue in either block legacy path or blk-mq. The current SCSI quiesce isn't safe and easy to trigger I/O deadlock. Once SCSI device is put into QUIESCE, no new request except for RQF_PREEMPT can be

[PATCH V7 3/6] block: pass flags to blk_queue_enter()

We need to pass PREEMPT flags to blk_queue_enter() for allocating request with RQF_PREEMPT in the following patch. Tested-by: Oleksandr Natalenko Tested-by: Martin Steigerwald Cc: Bart Van Assche Signed-off-by: Ming Lei