similar to: [PATCH 3.15 002/139] block: virtio_blk: dont hold spin lock during world switch

3.13.11.5 -stable review patch. If anyone has any objections, please let me know. ------------------ From: Ming Lei <ming.lei at canonical.com> commit e8edca6f7f92234202d6dd163c118ef495244d7c upstream. 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

3.13.11.5 -stable review patch. If anyone has any objections, please let me know. ------------------ From: Ming Lei <ming.lei at canonical.com> commit e8edca6f7f92234202d6dd163c118ef495244d7c upstream. 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

This is a note to let you know that I have just added a patch titled block: virtio_blk: don't hold spin lock during world switch to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree which can be found at: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue This patch is scheduled to be released in version 3.13.11.5. If you, or

This is a note to let you know that I have just added a patch titled block: virtio_blk: don't hold spin lock during world switch to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree which can be found at: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue This patch is scheduled to be released in version 3.13.11.5. If you, or

On Fri, May 30, 2014 at 10:49:29AM +0800, 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, qemu-arm), > so it isn't good to hold the lock and block other vCPUs. > > On arm64

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

Firstly this patch supports more than one virtual queues for virtio-blk device. Secondly this patch maps the virtual queue to blk-mq's hardware queue. With this approach, both scalability and performance can be improved. Signed-off-by: Ming Lei <ming.lei at canonical.com> --- drivers/block/virtio_blk.c | 70 +++++++++++++++++++++++++++++++------------- 1 file changed, 50

Firstly this patch supports more than one virtual queues for virtio-blk device. Secondly this patch maps the virtual queue to blk-mq's hardware queue. With this approach, both scalability and performance problem can be improved. Signed-off-by: Ming Lei <ming.lei at canonical.com> --- drivers/block/virtio_blk.c | 75 ++++++++++++++++++++++++++++++++------------ 1 file changed, 55

Firstly this patch supports more than one virtual queues for virtio-blk device. Secondly this patch maps the virtual queue to blk-mq's hardware queue. With this approach, both scalability and performance can be improved. Signed-off-by: Ming Lei <ming.lei at canonical.com> --- drivers/block/virtio_blk.c | 109 ++++++++++++++++++++++++++++++++++++-------- 1 file changed, 89

Firstly this patch supports more than one virtual queues for virtio-blk device. Secondly this patch maps the virtual queue to blk-mq's hardware queue. With this approach, both scalability and performance can be improved. Signed-off-by: Ming Lei <ming.lei at canonical.com> --- drivers/block/virtio_blk.c | 104 +++++++++++++++++++++++++++++++++++--------- 1 file changed, 84

On Fri, Jun 20, 2014 at 11:29:40PM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

On Fri, Jun 20, 2014 at 11:29:40PM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

On Thu, Jun 26, 2014 at 10:08:46AM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

On Thu, Jun 26, 2014 at 10:08:46AM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

Ming Lei <ming.lei at canonical.com> writes: > 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

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 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, qemu-arm), > so it isn't good to hold the lock and block other vCPUs. > > On arm64 quad core VM(qemu-kvm),

On 2014-05-29 21:34, Ming Lei wrote: > 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