search for: can_queue

v1 was here: https://lkml.org/lkml/2017/8/10/689 v1 -> v2: Remove .can_queue field from the templates. Rich.

v1 was here: https://lkml.org/lkml/2017/8/10/689 v1 -> v2: Remove .can_queue field from the templates. Rich.

Since switching to blk-mq as the default in commit 5c279bd9e406 ("scsi: default to scsi-mq"), virtio-scsi LUNs consume about 10x as much kernel memory. qemu currently allocates a fixed 128 entry virtqueue. can_queue currently is set to 1024. But with indirect descriptors, each command in the queue takes 1 virtqueue entry, so the number of commands which can be queued is equal to the length of the virtqueue. Note I intend to send a patch to qemu to allow the virtqueue size to be configured from the qemu comma...

Earlier discussion: https://lkml.org/lkml/2017/8/4/601 "Increased memory usage with scsi-mq" Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1478201

Earlier discussion: https://lkml.org/lkml/2017/8/4/601 "Increased memory usage with scsi-mq" Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1478201

Since switching to blk-mq as the default in commit 5c279bd9e406 ("scsi: default to scsi-mq"), virtio-scsi LUNs consume about 10x as much kernel memory. qemu currently allocates a fixed 128 entry virtqueue. can_queue currently is set to 1024. But with indirect descriptors, each command in the queue takes 1 virtqueue entry, so the number of commands which can be queued is equal to the length of the virtqueue. Note I intend to send a patch to qemu to allow the virtqueue size to be configured from the qemu comma...

...scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -1896,6 +1896,7 @@ int scsi_mq_setup_tags(struct Scsi_Host *shost) > shost->tag_set.ops = &scsi_mq_ops_no_commit; > shost->tag_set.nr_hw_queues = shost->nr_hw_queues ? : 1; > shost->tag_set.queue_depth = shost->can_queue; > + shost->tag_set.reserved_tags = shost->nr_reserved_cmds; You reserve tags for special usage, meantime the whole queue depth isn't increased, that means the tags for IO request is decreased given reserved tags can't be used for IO, so IO performance may be effected. If not the...

...scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -1896,6 +1896,7 @@ int scsi_mq_setup_tags(struct Scsi_Host *shost) > shost->tag_set.ops = &scsi_mq_ops_no_commit; > shost->tag_set.nr_hw_queues = shost->nr_hw_queues ? : 1; > shost->tag_set.queue_depth = shost->can_queue; > + shost->tag_set.reserved_tags = shost->nr_reserved_cmds; You reserve tags for special usage, meantime the whole queue depth isn't increased, that means the tags for IO request is decreased given reserved tags can't be used for IO, so IO performance may be effected. If not the...

...gt;h = h; > - c->scsi_cmd = SCSI_CMD_IDLE; > } > > static void hpsa_preinitialize_commands(struct ctlr_info *h) > @@ -5803,6 +5803,7 @@ static int hpsa_scsi_host_alloc(struct ctlr_info *h) > sh->max_lun = HPSA_MAX_LUN; > sh->max_id = HPSA_MAX_LUN; > sh->can_queue = h->nr_cmds - HPSA_NRESERVED_CMDS; > + sh->nr_reserved_cmds = HPSA_NRESERVED_CMDS; Now .nr_reserved_cmds has been passed to blk-mq, you need to increase sh->can_queue to h->nr_cmds, because .can_queue is the whole queue depth (include the part of reserved tags), otherwise, IO tags...

...+++ b/drivers/scsi/scsi_lib.c >> @@ -1896,6 +1896,7 @@ int scsi_mq_setup_tags(struct Scsi_Host *shost) >> shost->tag_set.ops = &scsi_mq_ops_no_commit; >> shost->tag_set.nr_hw_queues = shost->nr_hw_queues ? : 1; >> shost->tag_set.queue_depth = shost->can_queue; >> + shost->tag_set.reserved_tags = shost->nr_reserved_cmds; > > You reserve tags for special usage, meantime the whole queue depth > isn't increased, that means the tags for IO request is decreased given > reserved tags can't be used for IO, so IO performance may...

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches, which has already gone into virtio-next today. We hope this can go into virtio-next together with the virtio ring rework pathes. V6: rework "redo allocation of target data"

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches, which has already gone into virtio-next today. We hope this can go into virtio-next together with the virtio ring rework pathes. V6: rework "redo allocation of target data"

...96 May 2 10:15 active_mode -r--r--r--. 1 root root 4096 May 2 10:15 ahci_host_cap2 -r--r--r--. 1 root root 4096 May 2 10:15 ahci_host_caps -r--r--r--. 1 root root 4096 May 2 10:15 ahci_host_version -r--r--r--. 1 root root 4096 May 2 10:15 ahci_port_cmd -r--r--r--. 1 root root 4096 May 2 10:15 can_queue -r--r--r--. 1 root root 4096 May 2 10:15 cmd_per_lun lrwxrwxrwx. 1 root root 0 May 2 10:15 device -> ../../../host4/ -rw-r--r--. 1 root root 4096 May 2 10:15 eh_deadline -rw-r--r--. 1 root root 4096 May 2 10:15 em_buffer -rw-r--r--. 1 root root 4096 May 2 10:15 em_message -r--r--r--. 1 r...

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches, which has already gone into virtio-next today. We hope this can go into virtio-next together with the virtio ring rework pathes. V7: respin to fix the patch apply error V6: rework

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches, which has already gone into virtio-next today. We hope this can go into virtio-next together with the virtio ring rework pathes. V7: respin to fix the patch apply error V6: rework

James, patch 1 fixes scanning of LUNs whose number is greater than 255. QEMU passes a max_lun of 16383 (because it uses SAM numbering) but in Linux it must become 32768 (because LUNs above 255 are "relocated" to 16640). Patch 2 is a resubmission of the patch for online resizing of virtio-scsi LUNs, which needs to be rebased. LUNs above 255 now work for all of scanning, hotplug,

James, patch 1 fixes scanning of LUNs whose number is greater than 255. QEMU passes a max_lun of 16383 (because it uses SAM numbering) but in Linux it must become 32768 (because LUNs above 255 are "relocated" to 16640). Patch 2 is a resubmission of the patch for online resizing of virtio-scsi LUNs, which needs to be rebased. LUNs above 255 now work for all of scanning, hotplug,

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). The patches build on top of the new virtio APIs at http://permalink.gmane.org/gmane.linux.kernel.virtualization/18431; the new API simplifies the locking of the virtio-scsi driver nicely, thus it makes sense to require them as a prerequisite.

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). The patches build on top of the new virtio APIs at http://permalink.gmane.org/gmane.linux.kernel.virtualization/18431; the new API simplifies the locking of the virtio-scsi driver nicely, thus it makes sense to require them as a prerequisite.

This series implements virtio-scsi queue steering, which gives performance improvements of up to 50% (measured both with QEMU and tcm_vhost backends). This version rebased on Rusty's virtio ring rework patches. We hope this can go into virtio-next together with the virtio ring rework pathes. V5: improving the grammar of 1/5 (Paolo) move the dropping of sg_elems to 'virtio-scsi: use