On Mon, 11/14 16:29, Paolo Bonzini wrote:
>
>
> On 14/11/2016 16:26, Stefan Hajnoczi wrote:
> > On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
> >> QEMU_AIO_POLL_MAX_NS IOPs
> >>unset31,383
> >>146,860
> >>2
On 11/15/2016 04:32 AM, Stefan Hajnoczi wrote:
> On Mon, Nov 14, 2016 at 09:52:00PM +0100, Paolo Bonzini wrote:
>> On 14/11/2016 21:12, Karl Rister wrote:
>>> 25646,929
>>> 51235,627
>>>1,02446,477
>>>2,00035,247
>>>
On Mon, Nov 14, 2016 at 06:15:46PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 18:06, Stefan Hajnoczi wrote:
> >>> > > Very interesting that QEMU_AIO_POLL_MAX_NS=1 performs so well without
> >>> > > much CPU overhead.
> >> >
> >> > That basically means "avoid a syscall if you already know
On Mon, Nov 14, 2016 at 09:52:00PM +0100, Paolo Bonzini wrote:
> On 14/11/2016 21:12, Karl Rister wrote:
> > 25646,929
> > 51235,627
> >1,02446,477
> >2,00035,247
> >2,04846,322
> >
On 14/11/2016 21:12, Karl Rister wrote:
> 25646,929
> 51235,627
>1,02446,477
>2,00035,247
>2,04846,322
>4,00046,540
>4,09646,368
>8,000
On 11/14/2016 09:26 AM, Stefan Hajnoczi wrote:
> On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
>> On 11/09/2016 11:13 AM, Stefan Hajnoczi wrote:
>>> Recent performance investigation work done by Karl Rister shows that the
>>> guest->host notification takes around 20 us. This is
On 14/11/2016 18:06, Stefan Hajnoczi wrote:
>>> > > Very interesting that QEMU_AIO_POLL_MAX_NS=1 performs so well without
>>> > > much CPU overhead.
>> >
>> > That basically means "avoid a syscall if you already know there's
>> > something to do", so in retrospect it's not that surprising.
On Mon, Nov 14, 2016 at 04:29:49PM +0100, Paolo Bonzini wrote:
> On 14/11/2016 16:26, Stefan Hajnoczi wrote:
> > On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
> >> QEMU_AIO_POLL_MAX_NS IOPs
> >>unset31,383
> >>146,860
> >>
On Mon, 11/14 17:06, Stefan Hajnoczi wrote:
> On Mon, Nov 14, 2016 at 04:29:49PM +0100, Paolo Bonzini wrote:
> > On 14/11/2016 16:26, Stefan Hajnoczi wrote:
> > > On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
> > >> QEMU_AIO_POLL_MAX_NS IOPs
> > >>unset
On Mon, Nov 14, 2016 at 08:52:21AM -0600, Karl Rister wrote:
> On 11/14/2016 07:53 AM, Fam Zheng wrote:
> > On Fri, 11/11 13:59, Karl Rister wrote:
> >>
> >> Stefan
> >>
> >> I ran some quick tests with your patches and got some pretty good gains,
> >> but also some seemingly odd behavior.
> >>
>
On Mon, Nov 14, 2016 at 03:51:18PM +0100, Christian Borntraeger wrote:
> On 11/09/2016 06:13 PM, Stefan Hajnoczi wrote:
> > Recent performance investigation work done by Karl Rister shows that the
> > guest->host notification takes around 20 us. This is more than the
> > "overhead"
> > of QEMU
On Mon, Nov 14, 2016 at 03:59:32PM +0100, Christian Borntraeger wrote:
> On 11/09/2016 06:13 PM, Stefan Hajnoczi wrote:
> > Recent performance investigation work done by Karl Rister shows that the
> > guest->host notification takes around 20 us. This is more than the
> > "overhead"
> > of QEMU
On 11/14/2016 09:26 AM, Stefan Hajnoczi wrote:
> On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
>> On 11/09/2016 11:13 AM, Stefan Hajnoczi wrote:
>>> Recent performance investigation work done by Karl Rister shows that the
>>> guest->host notification takes around 20 us. This is
On 14/11/2016 16:26, Stefan Hajnoczi wrote:
> On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
>> QEMU_AIO_POLL_MAX_NS IOPs
>>unset31,383
>>146,860
>>246,440
>>435,246
>>
On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
> On 11/09/2016 11:13 AM, Stefan Hajnoczi wrote:
> > Recent performance investigation work done by Karl Rister shows that the
> > guest->host notification takes around 20 us. This is more than the
> > "overhead"
> > of QEMU itself
On 11/09/2016 06:13 PM, Stefan Hajnoczi wrote:
> Recent performance investigation work done by Karl Rister shows that the
> guest->host notification takes around 20 us. This is more than the "overhead"
> of QEMU itself (e.g. block layer).
>
> One way to avoid the costly exit is to use polling
On 11/09/2016 06:13 PM, Stefan Hajnoczi wrote:
> Recent performance investigation work done by Karl Rister shows that the
> guest->host notification takes around 20 us. This is more than the "overhead"
> of QEMU itself (e.g. block layer).
>
> One way to avoid the costly exit is to use polling
On 11/14/2016 07:53 AM, Fam Zheng wrote:
> On Fri, 11/11 13:59, Karl Rister wrote:
>>
>> Stefan
>>
>> I ran some quick tests with your patches and got some pretty good gains,
>> but also some seemingly odd behavior.
>>
>> These results are for a 5 minute test doing sequential 4KB requests from
>>
On Fri, 11/11 13:59, Karl Rister wrote:
>
> Stefan
>
> I ran some quick tests with your patches and got some pretty good gains,
> but also some seemingly odd behavior.
>
> These results are for a 5 minute test doing sequential 4KB requests from
> fio using O_DIRECT, libaio, and IO depth of 1.
Hi,
Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.
Type: series
Subject: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
Message-id: 1478711602-12620-1-git
On 11/09/2016 11:13 AM, Stefan Hajnoczi wrote:
> Recent performance investigation work done by Karl Rister shows that the
> guest->host notification takes around 20 us. This is more than the "overhead"
> of QEMU itself (e.g. block layer).
>
> One way to avoid the costly exit is to use polling
Recent performance investigation work done by Karl Rister shows that the
guest->host notification takes around 20 us. This is more than the "overhead"
of QEMU itself (e.g. block layer).
One way to avoid the costly exit is to use polling instead of notification.
The main drawback of polling is
22 matches
Mail list logo
