On Fri, Aug 25 2017 at  1:07pm -0400,
Ming Lei [off-list ref] wrote:

On Fri, Aug 25, 2017 at 12:32:33PM -0400, Mike Snitzer wrote:

quoted

On Fri, Aug 25 2017 at 12:08pm -0400,
Ming Lei [off-list ref] wrote:

quoted

On Fri, Aug 25, 2017 at 11:48:39AM -0400, Mike Snitzer wrote:

quoted

On Fri, Aug 25 2017 at 11:27am -0400,
Ming Lei [off-list ref] wrote:

quoted

We don't need to update orignal dm request partially
when ending each cloned bio, and this patch just
updates orignal dm request once when the whole
cloned request is finished.

Partial request update can be a bit expensive, so
we should try to avoid it, especially it is run
in softirq context.

After this patch is applied, both hard lockup and
soft lockup aren't reproduced any more in one hour
of running Laurence's test[1] on IB/SRP. Without
this patch, the lockup can be reproduced in several
minutes.

BTW, after d4acf3650c7c(block: Make blk_mq_delay_kick_requeue_list()
rerun the queue at a quiet time), we need to make the
test more aggressive for reproducing the lockup:

	1) run hammer_write.sh 32 or 64 concurrently.
	2) write 8M each time

[1] https://marc.info/?l=linux-block&m=150220185510245&w=2

Bart said he cannot reproduce the lockups with his patchset applied.
Have you tested using Bart's patchset?

d4acf3650c7c(block: Make blk_mq_delay_kick_requeue_list() rerun the
queue at a quiet time) has been in linus tree.

For other patches, I didn't test it yet. Because every time
when the lockup is triggered, it is always in blk_recalc_rq_segments(),
and not see any patch is dealing with that.

Please test with all of Bart's patches applied!

Just done the test with Bart's patch, still can
see soft lockup when running the test described
in commit log for a couple of minutes. BTW, my
test is much more aggressive than Laurence's, I
write 8M each time, and run 64 hammer_write.sh
concurrently.

OK, thanks for verifying as much.
 

I don't think the two are contradictory. Anyway,
this patch will decrease CPU utilization of SOFTIRQ, and
it is a improvement.

OK, looking closer I can see you accomplish the same (retaining partial
completion) in a more optimal way.

I'll include this in my review/staging of dm-multipath patches for 4.14.

Thanks,
Mike