search for: venkatash

...r the kernel has been booted? That would be nice, sure, but... > If so, anyone a hint about the best > way to do that would be much appreciated. ... I share your wonder and mystery at the ways of the block layer. Subject: virtio-blk: base queue-depth on virtqueue ringsize or module param Venkatash spake thus: virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). But behold, Ted added a module parameter: Als...

...r the kernel has been booted? That would be nice, sure, but... > If so, anyone a hint about the best > way to do that would be much appreciated. ... I share your wonder and mystery at the ways of the block layer. Subject: virtio-blk: base queue-depth on virtqueue ringsize or module param Venkatash spake thus: virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). But behold, Ted added a module parameter: Als...

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

...t;tytso at mit.edu> writes: > The current virtio block sets a queue depth of 64, which is > insufficient for very fast devices. It has been demonstrated that > with a high IOPS device, using a queue depth of 256 can double the > IOPS which can be sustained. > > As suggested by Venkatash Srinivas, set the queue depth by default to > be one half the the device's virtqueue, which is the maximum queue > depth that can be supported by the channel to the host OS (each I/O > request requires at least two VQ entries). > > Also allow the queue depth to be something which...

...t;tytso at mit.edu> writes: > The current virtio block sets a queue depth of 64, which is > insufficient for very fast devices. It has been demonstrated that > with a high IOPS device, using a queue depth of 256 can double the > IOPS which can be sustained. > > As suggested by Venkatash Srinivas, set the queue depth by default to > be one half the the device's virtqueue, which is the maximum queue > depth that can be supported by the channel to the host OS (each I/O > request requires at least two VQ entries). > > Also allow the queue depth to be something which...

On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas <venkateshs at google.com> wrote: >> And I rewrote it substantially, mainly to take >> VIRTIO_RING_F_INDIRECT_DESC into account. >> >> As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't >> have made a change. This version does (since QEMU also offers >> VIRTIO_RING_F_INDIRECT_DESC. > > That divide-by-2 produced the same queue depth as the prior > computation in QEMU was deliberate -- but raising it to 128 seems > pretty reasonable....

On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas <venkateshs at google.com> wrote: >> And I rewrote it substantially, mainly to take >> VIRTIO_RING_F_INDIRECT_DESC into account. >> >> As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't >> have made a change. This version does (since QEMU also offers >> VIRTIO_RING_F_INDIRECT_DESC. > > That divide-by-2 produced the same queue depth as the prior > computation in QEMU was deliberate -- but raising it to 128 seems > pretty reasonable....

The current virtio block sets a queue depth of 64, which is insufficient for very fast devices. It has been demonstrated that with a high IOPS device, using a queue depth of 256 can double the IOPS which can be sustained. As suggested by Venkatash Srinivas, set the queue depth by default to be one half the the device's virtqueue, which is the maximum queue depth that can be supported by the channel to the host OS (each I/O request requires at least two VQ entries). Also allow the queue depth to be something which can be set at module lo...

...400, Theodore Ts'o wrote: > The current virtio block sets a queue depth of 64, which is > insufficient for very fast devices. It has been demonstrated that > with a high IOPS device, using a queue depth of 256 can double the > IOPS which can be sustained. > > As suggested by Venkatash Srinivas, set the queue depth by default to > be one half the the device's virtqueue, which is the maximum queue > depth that can be supported by the channel to the host OS (each I/O > request requires at least two VQ entries). I don't think this should be a module parameter. The...

> And I rewrote it substantially, mainly to take > VIRTIO_RING_F_INDIRECT_DESC into account. > > As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't > have made a change. This version does (since QEMU also offers > VIRTIO_RING_F_INDIRECT_DESC. That divide-by-2 produced the same queue depth as the prior computation in QEMU was deliberate -- but raising it to 128 seems pretty reasonable. Signed-off-by: Venkatesh...

...om> writes: > On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas > <venkateshs at google.com> wrote: >>> And I rewrote it substantially, mainly to take >>> VIRTIO_RING_F_INDIRECT_DESC into account. >>> >>> As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't >>> have made a change. This version does (since QEMU also offers >>> VIRTIO_RING_F_INDIRECT_DESC. >> >> That divide-by-2 produced the same queue depth as the prior >> computation in QEMU was deliberate -- but raising it to 128 seems &gt...

...400, Theodore Ts'o wrote: > The current virtio block sets a queue depth of 64, which is > insufficient for very fast devices. It has been demonstrated that > with a high IOPS device, using a queue depth of 256 can double the > IOPS which can be sustained. > > As suggested by Venkatash Srinivas, set the queue depth by default to > be one half the the device's virtqueue, which is the maximum queue > depth that can be supported by the channel to the host OS (each I/O > request requires at least two VQ entries). I don't think this should be a module parameter. The...

...9;o <tytso at mit.edu> wrote: >The current virtio block sets a queue depth of 64, which is >insufficient for very fast devices. It has been demonstrated that >with a high IOPS device, using a queue depth of 256 can double the >IOPS which can be sustained. > >As suggested by Venkatash Srinivas, set the queue depth by default to >be one half the the device's virtqueue, which is the maximum queue >depth that can be supported by the channel to the host OS (each I/O >request requires at least two VQ entries). > >Also allow the queue depth to be something which can...

...9;o <tytso at mit.edu> wrote: >The current virtio block sets a queue depth of 64, which is >insufficient for very fast devices. It has been demonstrated that >with a high IOPS device, using a queue depth of 256 can double the >IOPS which can be sustained. > >As suggested by Venkatash Srinivas, set the queue depth by default to >be one half the the device's virtqueue, which is the maximum queue >depth that can be supported by the channel to the host OS (each I/O >request requires at least two VQ entries). > >Also allow the queue depth to be something which can...