Re: [PATCH] blk-mq: don't leak preempt counter/q_usage_counter when allocating rq failed

On Fri, Jul 14, 2017 at 04:41:36PM +0800, Ming Lei wrote: > From: Ming Lei > > When blk_mq_get_request() failed, preempt counter isn't > released, and blk_mq_make_request() doesn't release the counter > too. > > This patch fixes the issue, and makes sure that preempt counter

Re: [PATCH 03/14] blk-mq: introduce blk_mq_dispatch_rq_from_ctxs()

On Mon, Jul 31, 2017 at 11:09:38PM +, Bart Van Assche wrote: > On Tue, 2017-08-01 at 00:51 +0800, Ming Lei wrote: > > @@ -810,7 +810,11 @@ static void blk_mq_timeout_work(struct work_struct > > *work) > > > > struct ctx_iter_data { > > struct blk_mq_hw_ctx *hctx; > > - struct

[PATCH] sysfs: replace WARN() with pr_debug in sysfs_remove_group()

There is no enough error handling in block device adding/registration path, for example, device_add_disk() blk_register_queue() When kernel returns from device_add_disk(), no return value to tell us it was successful or not --- that suggests it would always succeed, and according to this

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

Michael Ellerman writes: > Brian King writes: > >> On 07/28/2017 10:17 AM, Brian J King wrote: >>> Jens Axboe wrote on 07/28/2017 09:25:48 AM: >>> Can you try the below fix? Should be more palatable than the previous

Re: [Xen-users] File-based domU - Slow storage write since xen 4.8

On Fri, Jul 28, 2017 at 04:50:27PM +0200, Benoit Depail wrote: > On 07/26/17 00:25, Keith Busch wrote: > > On Fri, Jul 21, 2017 at 07:07:06PM +0200, Benoit Depail wrote: > >> On 07/21/17 18:07, Roger Pau Monné wrote: > >>> > >>> Hm, I'm not sure I follow either. AFAIK this problem came from > >>>

Re: [PATCH] sysfs: replace WARN() with pr_debug in sysfs_remove_group()

Grep, On 2017/8/2 2:06, Greg KH wrote: On Tue, Aug 01, 2017 at 05:02:25PM +0900, Ethan Zhao wrote: There is no enough error handling in block device adding/registration path, for example, device_add_disk() blk_register_queue() When kernel returns from device_add_disk(), no return value

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

On Tue, Aug 01, 2017 at 04:14:07PM +, Bart Van Assche wrote: > On Tue, 2017-08-01 at 18:44 +0800, Ming Lei wrote: > > On Mon, Jul 31, 2017 at 11:42:21PM +, Bart Van Assche wrote: > > > Since setting, clearing and testing of BLK_MQ_S_BUSY can happen > > > concurrently > > > and since

Re: [PATCH 04/14] blk-mq-sched: improve dispatching from sw queue

On Tue, Aug 01, 2017 at 03:11:42PM +, Bart Van Assche wrote: > On Tue, 2017-08-01 at 18:50 +0800, Ming Lei wrote: > > On Tue, Aug 01, 2017 at 06:17:18PM +0800, Ming Lei wrote: > > > How can we get the accurate 'number of requests in progress' efficiently? > > Hello Ming, > > How about

[PATCH V2] blk-mq: don't leak preempt counter/q_usage_counter when allocating rq failed

From: Ming Lei When blk_mq_get_request() failed, preempt counter isn't released, and blk_mq_make_request() doesn't release the counter too. This patch fixes the issue, and makes sure that preempt counter is only held if rq is allocated successfully. The same policy is applied

Re: [PATCH] blk-mq: don't leak preempt counter/q_usage_counter when allocating rq failed

On Tue, Aug 01, 2017 at 09:18:23AM -0600, Jens Axboe wrote: > On 07/14/2017 02:41 AM, Ming Lei wrote: > > From: Ming Lei > > > > When blk_mq_get_request() failed, preempt counter isn't > > released, and blk_mq_make_request() doesn't release the counter > > too. > > > > This

[no subject]

subscribe linux-block

Drives Seizing Under Write Loads

Hello linux-block, My company is currently experiencing some problems with one particular brand of HDD. The symptoms are that the drive will experience extremely long IO wait times, extremely low IOPS, and near 100% disk utilization (see the following output from iostat). As a side effect of the

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

On 08/01/2017 12:55 AM, Michael Ellerman wrote: > Jens Axboe writes: > ... >> >> Can you try the below fix? Should be more palatable than the previous >> one. Brian, maybe you can take a look at the IRQ issue mentioned above? > > Given the patch from Brian fixed the lockdep

Re: [PATCH] blk-mq: don't leak preempt counter/q_usage_counter when allocating rq failed

On 07/14/2017 02:41 AM, Ming Lei wrote: > From: Ming Lei > > When blk_mq_get_request() failed, preempt counter isn't > released, and blk_mq_make_request() doesn't release the counter > too. > > This patch fixes the issue, and makes sure that preempt counter > is only held if

Re: [PATCH 04/14] blk-mq-sched: improve dispatching from sw queue

On Mon, Jul 31, 2017 at 11:34:35PM +, Bart Van Assche wrote: > On Tue, 2017-08-01 at 00:51 +0800, Ming Lei wrote: > > 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

Re: [PATCH 04/14] blk-mq-sched: improve dispatching from sw queue

On Tue, 2017-08-01 at 18:50 +0800, Ming Lei wrote: > On Tue, Aug 01, 2017 at 06:17:18PM +0800, Ming Lei wrote: > > 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

[PATCH] ipr: Fix scsi-mq lockdep issue

Fixes the following lockdep warning that can occur when scsi-mq is enabled with ipr due to ipr calling scsi_unblock_requests from irq context. The fix is to move the call to scsi_unblock_requests to ipr's existing workqueue. stack backtrace: CPU: 28 PID: 0 Comm: swapper/28 Not tainted

Re: [PATCH 04/14] blk-mq-sched: improve dispatching from sw queue

On Tue, Aug 01, 2017 at 06:17:18PM +0800, Ming Lei wrote: > On Mon, Jul 31, 2017 at 11:34:35PM +, Bart Van Assche wrote: > > On Tue, 2017-08-01 at 00:51 +0800, Ming Lei wrote: > > > SCSI devices use host-wide tagset, and the shared > > > driver tag space is often quite big. Meantime > > >

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

On Mon, Jul 31, 2017 at 11:42:21PM +, Bart Van Assche wrote: > On Tue, 2017-08-01 at 00:51 +0800, Ming Lei wrote: > > During dispatch, we moved all requests from hctx->dispatch to > > one temporary list, then dispatch them one by one from this list. > > Unfortunately duirng this period, run

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

Jens Axboe writes: ... > > Can you try the below fix? Should be more palatable than the previous > one. Brian, maybe you can take a look at the IRQ issue mentioned above? Given the patch from Brian fixed the lockdep warning, do you still want me to try and test this one? cheers

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

On Tue, 2017-08-01 at 18:44 +0800, Ming Lei wrote: > On Mon, Jul 31, 2017 at 11:42:21PM +, Bart Van Assche wrote: > > Since setting, clearing and testing of BLK_MQ_S_BUSY can happen concurrently > > and since clearing and testing happens without any locks held I'm afraid > > this > > patch

Re: [PATCH] sysfs: replace WARN() with pr_debug in sysfs_remove_group()

On Tue, Aug 01, 2017 at 05:02:25PM +0900, Ethan Zhao wrote: > There is no enough error handling in block device adding/registration > path, for example, > > device_add_disk() > blk_register_queue() > > When kernel returns from device_add_disk(), no return value to tell > us it was successful