Hi Paolo,
That will be great, I would like to hear more details about the design and
implementation once you get those ready.
Thanks a lot,
Wei
On 5/3/19, 11:05 AM, "Paolo Bonzini" wrote:
On 03/05/19 10:21, Wei Li wrote:
> Got it, thanks Stefan for your clarification!
Hi
On 03/05/19 10:21, Wei Li wrote:
> Got it, thanks Stefan for your clarification!
Hi Wei,
Stefan and I should be posting a patch to add Linux SCSI driver
batching, and an implementation for virtio-scsi.
Paolo
> Wei
>
> On 5/1/19, 9:36 AM, "Stefan Hajnoczi" wrote:
>
> On Mon, Apr 29,
Got it, thanks Stefan for your clarification!
Wei
On 5/1/19, 9:36 AM, "Stefan Hajnoczi" wrote:
On Mon, Apr 29, 2019 at 10:56:31AM -0700, Wei Li wrote:
>Does this mean the performance could be improved via adding Batch I/O
submission support in Guest driver side which will be able to
On Mon, Apr 29, 2019 at 10:56:31AM -0700, Wei Li wrote:
> Does this mean the performance could be improved via adding Batch I/O
> submission support in Guest driver side which will be able to reduce the
> number of virtqueue kicks?
Yes, I think so. It's not obvious to me how a Linux SCSI
On 29/04/19 15:40, Stefan Hajnoczi wrote:
> This isn't fully effective since the guest driver kicks once per
> request. Therefore QEMU-level batching you mentioned only works if QEMU
> is slower at handling virtqueue kicks than the guest is at submitting
> requests.
>
> I wonder if this is
Thanks Stefan!
Does this mean the performance could be improved via adding Batch I/O
submission support in Guest driver side which will be able to reduce the number
of virtqueue kicks?
Thanks,
Wei
On 4/29/19, 6:40 AM, "Stefan Hajnoczi" wrote:
On Fri, Apr 26, 2019 at 10:14:16AM +0200,
Thanks Paolo for your clarification!
Just wanted to double confirm, does this mean batch I/O submission won't apply
to aio=threads (which is the default mode)?
Thanks,
Wei
On 4/26/19, 9:25 PM, "Paolo Bonzini" wrote:
> Thanks Stefan and Paolo for your response and advice!
>
On Fri, Apr 26, 2019 at 10:14:16AM +0200, Paolo Bonzini wrote:
> On 23/04/19 14:04, Stefan Hajnoczi wrote:
> >> In addition, does Virtio-scsi support Batch I/O Submission feature
> >> which may be able to increase the IOPS via reducing the number of
> >> system calls?
> >
> > I don't see obvious
> Thanks Stefan and Paolo for your response and advice!
>
> Hi Paolo,
>
> As to the virtio-scsi batch I/O submission feature in QEMU which you
> mentioned, is this feature turned on by default in QEMU 2.9 or there is a
> tunable parameters to turn on/off the feature?
Yes, it is available by
Thanks Stefan and Paolo for your response and advice!
Hi Paolo,
As to the virtio-scsi batch I/O submission feature in QEMU which you mentioned,
is this feature turned on by default in QEMU 2.9 or there is a tunable
parameters to turn on/off the feature?
Thanks,
Wei
On 4/26/19, 1:14 AM,
On 23/04/19 14:04, Stefan Hajnoczi wrote:
>> In addition, does Virtio-scsi support Batch I/O Submission feature
>> which may be able to increase the IOPS via reducing the number of
>> system calls?
>
> I don't see obvious batching support in drivers/scsi/virtio_scsi.c.
> The Linux block layer
On Mon, Apr 22, 2019 at 09:21:53PM -0700, Wei Li wrote:
> 2. kvm_stat or perf record -a -e kvm:\* counters for vmexits and
>interrupt injections. If these counters vary greatly between queue
>sizes, then that is usually a clue. It's possible to get higher
>
Hi Stefan,
I did investigation per your advices, please see inline for the details and
questions.
1. Compare "iostat -dx 1" inside the guest and host. Are the I/O
patterns comparable? blktrace(8) can give you even more detail on
the exact I/O patterns. If the
Sounds good, let's keep in touch. __
Thanks,
Wei
On 4/17/19, 5:17 AM, "Paolo Bonzini" wrote:
On 17/04/19 03:38, Wei Li wrote:
> Thanks Paolo for your response and clarification.
>
> Btw, is there any rough schedule about when are you planning to start
> working on the
On 17/04/19 03:38, Wei Li wrote:
> Thanks Paolo for your response and clarification.
>
> Btw, is there any rough schedule about when are you planning to start
> working on the multi queue feature? Once you start working on the
> feature, I would like to hear more details about the design and
>
Thanks Stefan and Dongli for your feedback and advices!
I will do the further investigation per your advices and get back to you later
on.
Thanks,
-Wei
On 4/16/19, 2:20 AM, "Stefan Hajnoczi" wrote:
On Tue, Apr 16, 2019 at 07:23:38AM +0800, Dongli Zhang wrote:
>
>
> On
Thanks Paolo for your response and clarification.
Btw, is there any rough schedule about when are you planning to start working
on the multi queue feature? Once you start working on the feature, I would
like to hear more details about the design and better understand how this
feature will
On 05/04/19 23:09, Wei Li wrote:
> Thanks Stefan for your quick response!
>
> Hi Paolo, Could you please send us a link related to the multiqueue
> feature which you are working on so that we could start getting some
> details about the feature.
I have never gotten to the point of multiqueue, a
On Tue, Apr 16, 2019 at 07:23:38AM +0800, Dongli Zhang wrote:
>
>
> On 4/16/19 1:34 AM, Wei Li wrote:
> > Hi @Paolo Bonzini & @Stefan Hajnoczi,
> >
> > Would you please help confirm whether @Paolo Bonzini's multiqueue feature
> > change will benefit virtio-scsi or not? Thanks!
> >
> > @Stefan
On 4/16/19 1:34 AM, Wei Li wrote:
> Hi @Paolo Bonzini & @Stefan Hajnoczi,
>
> Would you please help confirm whether @Paolo Bonzini's multiqueue feature
> change will benefit virtio-scsi or not? Thanks!
>
> @Stefan Hajnoczi,
> I also spent some time on exploring the virtio-scsi multi-queue
Hi @Paolo Bonzini & @Stefan Hajnoczi,
Would you please help confirm whether @Paolo Bonzini's multiqueue feature
change will benefit virtio-scsi or not? Thanks!
@Stefan Hajnoczi,
I also spent some time on exploring the virtio-scsi multi-queue features via
num_queues parameter as below, here are
Thanks Stefan for your quick response!
Hi Paolo,
Could you please send us a link related to the multiqueue feature which you are
working on so that we could start getting some details about the feature.
Thanks again,
Wei
On 4/1/19, 3:54 AM, "Stefan Hajnoczi" wrote:
On Fri, Mar 29, 2019
On Fri, Mar 29, 2019 at 08:16:36AM -0700, Wei Li wrote:
> Thanks Stefan for your reply and guidance!
>
> We spent some time on exploring the multiple I/O Threads approach per your
> feedback. Based on the perf measurement data, we did see some IOPS
> improvement for multiple volumes, which is
Thanks Stefan for your reply and guidance!
We spent some time on exploring the multiple I/O Threads approach per your
feedback. Based on the perf measurement data, we did see some IOPS improvement
for multiple volumes, which is great. :)
In addition, IOPS for single Volume will still be a
On Mon, Mar 04, 2019 at 09:33:26AM -0800, Wei Li wrote:
> While @Stefan mentioned about additional iothread object support of
> virtio-blk, Is the feature also supported by virtio-scsi? I am trying to
> exploring the perf multiple IO threads / per VM via followings:
> QMP setup example to create
Hi Stefan and all,
I spent some time on getting familiar with QEMU and relevant concepts. My
project is using QEMU 2.9 with virtio-scsi backend, and I am exploring proper
way to improve the IOPS of my project.
Thanks @Stefan for the response and advices!
Could you please help review
26 matches
Mail list logo
