Hi Paolo,
On Mon, Dec 14, 2015 at 6:31 PM, Paolo Bonzini wrote:
>
>
> On 18/06/2014 06:04, Ming Lei wrote:
>> For virtio-blk, I don't think it is always better to take more queues, and
>> we need to leverage below things in host side:
>>
>> - host storage top performance, generally it reaches
On 18/06/2014 06:04, Ming Lei wrote:
> For virtio-blk, I don't think it is always better to take more queues, and
> we need to leverage below things in host side:
>
> - host storage top performance, generally it reaches that with more
> than 1 jobs with libaio(suppose it is N, so basically we
Hi Paolo,
On Mon, Dec 14, 2015 at 6:31 PM, Paolo Bonzini wrote:
>
>
> On 18/06/2014 06:04, Ming Lei wrote:
>> For virtio-blk, I don't think it is always better to take more queues, and
>> we need to leverage below things in host side:
>>
>> - host storage top performance,
On 18/06/2014 06:04, Ming Lei wrote:
> For virtio-blk, I don't think it is always better to take more queues, and
> we need to leverage below things in host side:
>
> - host storage top performance, generally it reaches that with more
> than 1 jobs with libaio(suppose it is N, so basically we
On Wed, Jun 18, 2014 at 12:34 AM, Paolo Bonzini wrote:
> Il 17/06/2014 18:00, Ming Lei ha scritto:
>
>>> > If you want to do queue steering based on the guest VCPU number, the
>>> > number
>>> > of queues must be = to the number of VCPUs shouldn't it?
>>> >
>>> > I tried using a divisor of the
Il 17/06/2014 18:00, Ming Lei ha scritto:
> If you want to do queue steering based on the guest VCPU number, the number
> of queues must be = to the number of VCPUs shouldn't it?
>
> I tried using a divisor of the number of VCPUs, but couldn't get the block
> layer to deliver interrupts to the
On Tue, Jun 17, 2014 at 11:53 PM, Paolo Bonzini wrote:
> Il 17/06/2014 17:50, Ming Lei ha scritto:
>
>>> > It would be nice to allocate virtqueues dynamically instead of
>>> > hardcoding the limit. virtio-scsi also allocates virtqueues
>>> > dynamically.
>>
>> virtio-scsi may have lots of LUN,
Il 17/06/2014 17:50, Ming Lei ha scritto:
> It would be nice to allocate virtqueues dynamically instead of
> hardcoding the limit. virtio-scsi also allocates virtqueues
> dynamically.
virtio-scsi may have lots of LUN, but virtio-blk only has one disk
which needn't lots of hardware queues.
If
On Tue, Jun 17, 2014 at 10:40 AM, Stefan Hajnoczi wrote:
> On Sat, Jun 14, 2014 at 1:29 AM, 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,
On Tue, Jun 17, 2014 at 10:40 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Sat, Jun 14, 2014 at 1:29 AM, Ming Lei ming@canonical.com 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
Il 17/06/2014 17:50, Ming Lei ha scritto:
It would be nice to allocate virtqueues dynamically instead of
hardcoding the limit. virtio-scsi also allocates virtqueues
dynamically.
virtio-scsi may have lots of LUN, but virtio-blk only has one disk
which needn't lots of hardware queues.
If
On Tue, Jun 17, 2014 at 11:53 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 17/06/2014 17:50, Ming Lei ha scritto:
It would be nice to allocate virtqueues dynamically instead of
hardcoding the limit. virtio-scsi also allocates virtqueues
dynamically.
virtio-scsi may have lots of LUN,
Il 17/06/2014 18:00, Ming Lei ha scritto:
If you want to do queue steering based on the guest VCPU number, the number
of queues must be = to the number of VCPUs shouldn't it?
I tried using a divisor of the number of VCPUs, but couldn't get the block
layer to deliver interrupts to the right
On Wed, Jun 18, 2014 at 12:34 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 17/06/2014 18:00, Ming Lei ha scritto:
If you want to do queue steering based on the guest VCPU number, the
number
of queues must be = to the number of VCPUs shouldn't it?
I tried using a divisor of the
On Sat, Jun 14, 2014 at 1:29 AM, 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 problem can be improved.
>
>
Ming Lei writes:
> + if (virtio_has_feature(vdev, VIRTIO_BLK_F_MQ))
> + err = virtio_cread_feature(vdev, VIRTIO_BLK_F_MQ,
> +struct virtio_blk_config, num_queues,
> +_vqs);
> + else
> + num_vqs = 1;
Ming Lei ming@canonical.com writes:
+ if (virtio_has_feature(vdev, VIRTIO_BLK_F_MQ))
+ err = virtio_cread_feature(vdev, VIRTIO_BLK_F_MQ,
+struct virtio_blk_config, num_queues,
+num_vqs);
+ else
+
On Sat, Jun 14, 2014 at 1:29 AM, Ming Lei ming@canonical.com 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 problem can be
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
---
drivers/block/virtio_blk.c | 75
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@canonical.com
---
20 matches
Mail list logo