similar to: [PATCH] block: virtio_blk: don't hold spin lock during world switch

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

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,

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

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, This patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance problems on virtio-blk device get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq

Hi, This patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance problems on virtio-blk device get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

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

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

3.15-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 time on

3.15-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 time on

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> > --- >

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> > --- >