similar to: [PATCH] virtio_blk: merge S/G list entries by default

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

On Mon, Sep 08, 2014 at 11:18:30AM +0300, Michael S. Tsirkin wrote: > Could you respond to Ming Lei's mail, who benchmarked the patch, please? I don't really have any additional data or disagreement, not sure what I should respond there.

On Mon, Sep 08, 2014 at 11:18:30AM +0300, Michael S. Tsirkin wrote: > Could you respond to Ming Lei's mail, who benchmarked the patch, please? I don't really have any additional data or disagreement, not sure what I should respond there.

On Fri, Sep 08, 2023 at 08:44:45AM -0600, Jens Axboe wrote: > On 9/8/23 8:34 AM, Ming Lei wrote: > > On Fri, Sep 08, 2023 at 07:49:53AM -0600, Jens Axboe wrote: > >> On 9/8/23 3:30 AM, Ming Lei wrote: > >>> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c > >>> index ad636954abae..95a3d31a1ef1 100644 > >>> --- a/io_uring/io_uring.c >

On Fri, Sep 08, 2023 at 08:44:45AM -0600, Jens Axboe wrote: > On 9/8/23 8:34 AM, Ming Lei wrote: > > On Fri, Sep 08, 2023 at 07:49:53AM -0600, Jens Axboe wrote: > >> On 9/8/23 3:30 AM, Ming Lei wrote: > >>> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c > >>> index ad636954abae..95a3d31a1ef1 100644 > >>> --- a/io_uring/io_uring.c >

On Sun, Sep 07, 2014 at 02:41:53PM +0300, Michael S. Tsirkin wrote: > > Signed-off-by: Christoph Hellwig <hch at lst.de> > > OK so this is an optimization patch right? > What kind of performance gain is observed with it? None. I actually wrote it when the block layer had a bug when dm was used on top of the !merge case, and I decided to send it out as there had been no

On Sun, Sep 07, 2014 at 02:41:53PM +0300, Michael S. Tsirkin wrote: > > Signed-off-by: Christoph Hellwig <hch at lst.de> > > OK so this is an optimization patch right? > What kind of performance gain is observed with it? None. I actually wrote it when the block layer had a bug when dm was used on top of the !merge case, and I decided to send it out as there had been no

Firstly, it isn't necessary to hold lock of vblk->vq_lock when notifying hypervisor about queued I/O. Secondly, virtqueue_notify() will cause world switch and it may take long time on some hypervisors(such as, qemu-arm), so it isn't good to hold the lock and block other vCPUs. On arm64 quad core VM(qemu-kvm), the patch can increase I/O performance a lot with VIRTIO_RING_F_EVENT_IDX

Firstly, it isn't necessary to hold lock of vblk->vq_lock when notifying hypervisor about queued I/O. Secondly, virtqueue_notify() will cause world switch and it may take long time on some hypervisors(such as, qemu-arm), so it isn't good to hold the lock and block other vCPUs. On arm64 quad core VM(qemu-kvm), the patch can increase I/O performance a lot with VIRTIO_RING_F_EVENT_IDX

On Mon, Nov 10, 2014 at 7:59 PM, Luk?? Czerner <lczerner at redhat.com> wrote: > > Hi, > > so I encountered it again on 3.17.0-rc4. This output is from the > run with your patch. > > I am using libvirt (virt-manager) to configure and run the virtual > machine, but looking at the xml, I do not think it's passing > 'scsi=off' at all. > > Btw, that

On Mon, Nov 10, 2014 at 7:59 PM, Luk?? Czerner <lczerner at redhat.com> wrote: > > Hi, > > so I encountered it again on 3.17.0-rc4. This output is from the > run with your patch. > > I am using libvirt (virt-manager) to configure and run the virtual > machine, but looking at the xml, I do not think it's passing > 'scsi=off' at all. > > Btw, that

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. To fix, cleanup in reverse order of initialization. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. To fix, cleanup in reverse order of initialization. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1

On Fri, May 30, 2014 at 11:19 AM, Jens Axboe <axboe at kernel.dk> wrote: > On 2014-05-29 20:49, Ming Lei wrote: >> >> Firstly, it isn't necessary to hold lock of vblk->vq_lock >> when notifying hypervisor about queued I/O. >> >> Secondly, virtqueue_notify() will cause world switch and >> it may take long time on some hypervisors(such as,

On Fri, May 30, 2014 at 11:19 AM, Jens Axboe <axboe at kernel.dk> wrote: > On 2014-05-29 20:49, Ming Lei wrote: >> >> Firstly, it isn't necessary to hold lock of vblk->vq_lock >> when notifying hypervisor about queued I/O. >> >> Secondly, virtqueue_notify() will cause world switch and >> it may take long time on some hypervisors(such as,

On 11/11/2014 09:42 AM, Ming Lei wrote: > The attached patch should fix the problem, and hope it is the last one, :-) Dongsu and Jeff, any of you test this variant? I think this is the last one, at least I hope so as well... -- Jens Axboe

On 11/11/2014 09:42 AM, Ming Lei wrote: > The attached patch should fix the problem, and hope it is the last one, :-) Dongsu and Jeff, any of you test this variant? I think this is the last one, at least I hope so as well... -- Jens Axboe

On Sun, Sep 07, 2014 at 08:47:45PM +0200, Christoph Hellwig wrote: > On Sun, Sep 07, 2014 at 02:41:53PM +0300, Michael S. Tsirkin wrote: > > > Signed-off-by: Christoph Hellwig <hch at lst.de> > > > > OK so this is an optimization patch right? > > What kind of performance gain is observed with it? > > None. I actually wrote it when the block layer had a

On 2014-11-10 02:59, Rusty Russell wrote: > Jeff Layton <jlayton at poochiereds.net> writes: > >> In the latest Fedora rawhide kernel in the repos, I'm seeing the >> following oops when mounting xfs. rc2-ish kernels seem to be fine: >> >> [ 64.669633] ------------[ cut here ]------------ >> [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172!