On 02/20/2016 07:12 AM, Mike Snitzer wrote:
On Fri, Feb 19 2016 at  2:42pm -0500,
Mike Snitzer <[email protected]> wrote:

On Fri, Feb 19 2016 at  3:37am -0500,
Junichi Nomura <[email protected]> wrote:

On 02/19/16 09:33, Nomura Junichi wrote:
On 02/19/16 02:17, Mike Snitzer wrote:
What is the last kernel version that your scripts have worked on?

v4.4 worked fine. I'll check with v4.5-rc4 when I get a machine.

v4.5-rc4 works fine, too.

Have you been running with blk-mq?
Either by setting CONFIG_DM_MQ_DEFAULT or:
echo Y > /sys/module/dm_mod/parameters/use_blk_mq

I'm seeing test_02_sdev_delete fail with blk-mq enabled.

I only see failure if I stack dm-mq ontop of old non-mq scsi devices with:

echo N > /sys/module/scsi_mod/parameters/use_blk_mq
echo Y > /sys/module/dm_mod/parameters/use_blk_mq

If I use scsi-mq for the underlying devices all works fine (been testing
the latest dm-4.6 branch though, I'll go back and try stock 4.5-rc4 just
to double check).

But this makes me think the novelty of having dm-mq support stacking on
non-blk-mq devices was misplaced.  It is a senseless config.  I'll
probably remove support for such stacking soon (next week).

Hmm. I must admit I really, really don't like these 'once-and-for-all'
parameter.

ATM the only SCSI driver to support SCSI-mq properly are lpfc, virtio, and fnic. None of the other driver have been modified, and I suspect the performance might be less than stellar.

So there will be configurations where one might want to run scsi-mq alongside non-mq HBAs.

I would really love to see to make that more granular so that these configurations can run efficiently. I know Christoph is violently against it, but I don't really see any solution presenting itself at the moment.

Maybe a good topic for LSF ...

Cheers,

Hannes
--
Dr. Hannes Reinecke                   zSeries & Storage
[email protected]                          +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Reply via email to