On 02/20/2016 07:12 AM, Mike Snitzer wrote:
On Fri, Feb 19 2016 at 2:42pm -0500,
Mike Snitzer <snitzer@xxxxxxxxxx> wrote:
On Fri, Feb 19 2016 at 3:37am -0500,
Junichi Nomura <j-nomura@xxxxxxxxxxxxx> 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
hare@xxxxxxx +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)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
