qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Frediano Ziglio <freddy77@gmail.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] Default cache mode
Date: Wed, 29 Jun 2011 15:53:40 +0200	[thread overview]
Message-ID: <BANLkTim06=XmPFJXXHv7ZTrHnF6Mb_eaBQ@mail.gmail.com> (raw)
In-Reply-To: <4E0B1943.4090400@codemonkey.ws>

2011/6/29 Anthony Liguori <anthony@codemonkey.ws>:
> On 06/29/2011 07:16 AM, Kevin Wolf wrote:
>>
>> Am 29.06.2011 14:06, schrieb Anthony Liguori:
>>>
>>> On 06/29/2011 06:59 AM, Kevin Wolf wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think we have touched this topic before during some IRC discussions or
>>>> somewhere deep in a mailing list thread, but I think it hasn't been
>>>> discussed on the list.
>>>>
>>>> Our default cache mode of cache=writethrough is extremely conservative
>>>> and provides absolute safety at the cost of performance,
>>>
>>> But for the most part, we track bare metal fairly well in terms of block
>>> performance, no?
>>>
>>> Or are you really referring to qcow2 as a specific example?  In the
>>> past, we used a different default caching mode for qcow2.  I think that
>>> could be done again if there was a compelling reason.
>>
>> No, people are also complaining about bad performance with raw. Which
>> isn't really surprising when you do a flush after each single write
>> request. O_SYNC is really much more than is needed in the average case.
>
> Which file system on the host?
>
> At any rate, I'm a big fan of making wce tunable in the guest and then I
> think setting wce=1 is quite reasonable to do by default.
>
> Regards,
>
> Anthony Liguori
>
>>
>> Kevin
>
>
>

Personally I think default lead to poor performance but currently
people know that even critical application are handled correctly.
Assuming a client connect to a database server on a qemu guest when
server reply "transaction ok" you know that even a host crash lead to
a successful transaction. At least the fact that this assumption won't
be true has to be stated.

Lately I'm doing some extensive testing on image performance and I
noted that are not only image dependent but also filesystem (where
image is stored) dependent but when data are allocated speed is good.
raw disks are not so fast as expected? Try to use fallocate command to
allocate the file than do a dd to fill the entire file with zeros and
writethrough will perform very well. Allocating raw with qemu-img lead
to a normal sparse file which written with O_DSYNC flag is quite slow
due to extents allocation and fragmentation.

Regards
 Frediano Ziglio

  parent reply	other threads:[~2011-06-29 13:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-29 11:59 [Qemu-devel] Default cache mode Kevin Wolf
2011-06-29 12:06 ` Anthony Liguori
2011-06-29 12:16   ` Kevin Wolf
2011-06-29 12:23     ` Anthony Liguori
2011-06-29 12:32       ` Kevin Wolf
2011-06-29 13:51         ` Christoph Hellwig
2011-06-29 14:17         ` Michael Tokarev
2011-06-29 14:50           ` Christoph Hellwig
2011-06-29 15:07             ` Michael Tokarev
2011-06-29 13:50       ` Christoph Hellwig
2011-06-29 14:13         ` Anthony Liguori
2011-06-29 14:47           ` Christoph Hellwig
2011-06-29 16:03           ` Stefan Hajnoczi
2011-06-29 13:53       ` Frediano Ziglio [this message]
2011-06-29 14:11         ` Kevin Wolf
2011-06-29 14:12           ` Christoph Hellwig
2011-06-29 14:21             ` Kevin Wolf
2011-06-29 13:49   ` Christoph Hellwig
2011-06-29 12:08 ` Anthony Liguori
2011-06-29 13:55   ` Christoph Hellwig
2011-06-29 14:20     ` Anthony Liguori
2011-06-29 14:52       ` Christoph Hellwig
2011-06-29 15:26         ` Anthony Liguori
2011-06-29 12:21 ` Alexander Graf
2011-06-29 13:57   ` Stefan Hajnoczi
2011-06-29 14:05     ` Alexander Graf
2011-06-29 12:52 ` Stefan Hajnoczi
2011-06-29 13:56   ` Christoph Hellwig
2011-06-29 13:00 ` Avi Kivity
2011-06-29 13:05   ` Anthony Liguori
2011-06-29 13:30     ` Avi Kivity
2011-06-29 13:11   ` Kevin Wolf

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='BANLkTim06=XmPFJXXHv7ZTrHnF6Mb_eaBQ@mail.gmail.com' \
    --to=freddy77@gmail.com \
    --cc=Qemu-devel@nongnu.org \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=hch@lst.de \
    --cc=kwolf@redhat.com \
    --cc=stefanha@linux.vnet.ibm.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).