From: Kevin Wolf <kwolf@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
Stefan Hajnoczi <stefanha@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/2] raw-posix: warn about BDRV_O_NATIVE_AIO if libaio is unavailable
Date: Thu, 23 Jul 2015 13:58:00 +0200 [thread overview]
Message-ID: <20150723115800.GE4314@noname.redhat.com> (raw)
In-Reply-To: <55B0BD55.4010600@de.ibm.com>
Am 23.07.2015 um 12:09 hat Christian Borntraeger geschrieben:
> Am 17.07.2015 um 16:23 schrieb Stefan Hajnoczi:
> > raw-posix.c silently ignores BDRV_O_NATIVE_AIO if libaio is unavailable.
> > It is confusing when aio=native performance is identical to aio=threads
> > because the binary was accidentally built without libaio.
> >
> > Print a deprecation warning if -drive aio=native is used with a binary
> > that does not support libaio. There are probably users using aio=native
> > who would be inconvenienced if QEMU suddenly refused to start their
> > guests. In the future this will become an error.
> >
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>
> had that myself on a freshly installed system without libaio-devel.
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
>
>
> Another thing. Would it make sense to change the default to aio=native somewhen?
> From what I can tell this seems to outperform aio=threads in most cases.
aio=native requires cache.direct=on, which is not portable to all
platforms that qemu supports, and also doesn't work with all filesystems
on Linux (most notably tmpfs fails). Also recent benchmarks seem to
suggest that currently there is no clear winner between aio=native and
aio=threads, it depends too much on the host storage and the workload.
When we discussed the default cache mode a while back (with the options
cache=writeback and cache=none), it was considered more important to
have a default setting that works everywhere and performs good for quick
ad-hoc VMs and development/debugging work than one that performs best in
enterprise setups that should use a management tool anyway.
Kevin
next prev parent reply other threads:[~2015-07-23 11:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 14:23 [Qemu-devel] [PATCH v2 0/2] block: warn about aio=native if libaio is unavailable Stefan Hajnoczi
2015-07-17 14:23 ` [Qemu-devel] [PATCH v2 1/2] raw-posix: warn about BDRV_O_NATIVE_AIO " Stefan Hajnoczi
2015-07-23 10:09 ` Christian Borntraeger
2015-07-23 10:11 ` Denis V. Lunev
2015-07-23 11:58 ` Kevin Wolf [this message]
2015-07-17 14:23 ` [Qemu-devel] [PATCH v2 2/2] blockdev: always compile in -drive aio= parsing Stefan Hajnoczi
2015-07-23 7:58 ` Markus Armbruster
2015-07-23 8:03 ` [Qemu-devel] [PATCH v2 0/2] block: warn about aio=native if libaio is unavailable Markus Armbruster
2015-07-23 8:08 ` Paolo Bonzini
2015-07-23 8:15 ` Kevin Wolf
2015-07-23 12:06 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150723115800.GE4314@noname.redhat.com \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).