similar to: [PATCH] virtio-blk: make the queue depth configurable

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

On March 14, 2014 11:34:31 PM EDT, Theodore Ts'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

On March 14, 2014 11:34:31 PM EDT, Theodore Ts'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

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

tytso at mit.edu writes: > On Mon, Mar 17, 2014 at 11:12:15AM +1030, Rusty Russell wrote: >> >> Note that with indirect descriptors (which is supported by Almost >> Everyone), we can actually use the full index, so this value is a bit >> pessimistic. But it's OK as a starting point. > > So is this something that can go upstream with perhaps a slight >

tytso at mit.edu writes: > On Mon, Mar 17, 2014 at 11:12:15AM +1030, Rusty Russell wrote: >> >> Note that with indirect descriptors (which is supported by Almost >> Everyone), we can actually use the full index, so this value is a bit >> pessimistic. But it's OK as a starting point. > > So is this something that can go upstream with perhaps a slight >

On Fri, 2014-03-14 at 13:31 -0400, Theodore Ts'o wrote: > The current virtio block sets a queue depth of 64. With a > sufficiently fast device, using a queue depth of 256 can double the > IOPS which can be sustained. So make the queue depth something which > can be set at module load time or via a kernel boot-time parameter. [] > diff --git a/drivers/block/virtio_blk.c

Theodore Ts'o <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

Theodore Ts'o <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

Linux kernel only supports logical block sizes which are power of two, at least 512 bytes and no more that PAGE_SIZE. Check this instead of crashing later on. Note that there is no need to check physical block size since it is only a hint, and virtio-blk already only supports power of two values. Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=1664619 Signed-off-by: Maxim Levitsky

Linux kernel only supports logical block sizes which are power of two, at least 512 bytes and no more that PAGE_SIZE. Check this instead of crashing later on. Note that there is no need to check physical block size since it is only a hint, and virtio-blk already only supports power of two values. Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=1664619 Signed-off-by: Maxim Levitsky

On Wed, 2020-07-15 at 06:06 -0400, Michael S. Tsirkin wrote: > On Wed, Jul 15, 2020 at 12:55:18PM +0300, Maxim Levitsky wrote: > > Linux kernel only supports logical block sizes which are power of > > two, > > at least 512 bytes and no more that PAGE_SIZE. > > > > Check this instead of crashing later on. > > > > Note that there is no need to check

On Wed, 2020-07-15 at 06:06 -0400, Michael S. Tsirkin wrote: > On Wed, Jul 15, 2020 at 12:55:18PM +0300, Maxim Levitsky wrote: > > Linux kernel only supports logical block sizes which are power of > > two, > > at least 512 bytes and no more that PAGE_SIZE. > > > > Check this instead of crashing later on. > > > > Note that there is no need to check

On Fri, Mar 14, 2014 at 10:38:40AM -0700, Joe Perches wrote: > > +static int queue_depth = 64; > > +module_param(queue_depth, int, 444); > > 444? Really Ted? Oops, *blush*. Thanks for catching that. - Ted

On Fri, Mar 14, 2014 at 10:38:40AM -0700, Joe Perches wrote: > > +static int queue_depth = 64; > > +module_param(queue_depth, int, 444); > > 444? Really Ted? Oops, *blush*. Thanks for catching that. - Ted

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng

Most virtio setups have a fairly limited number of ring entries available. Enable S/G entry merging by default to fit into less of them. This restores the behavior at time of the virtio-blk blk-mq conversion, which was changed by commit "block: add queue flag for disabling SG merging" which made the behavior optional, but didn't update the existing drivers to keep their previous

Most virtio setups have a fairly limited number of ring entries available. Enable S/G entry merging by default to fit into less of them. This restores the behavior at time of the virtio-blk blk-mq conversion, which was changed by commit "block: add queue flag for disabling SG merging" which made the behavior optional, but didn't update the existing drivers to keep their previous