All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: aliguro@us.ibm.com, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, Zhi Yong Wu <zwu.kernel@gmail.com>,
	ryanh@us.ibm.com
Subject: Re: [Qemu-devel] Why qemu write/rw speed is so low?
Date: Fri, 09 Sep 2011 16:04:07 +0200	[thread overview]
Message-ID: <4E6A1CD7.70300@redhat.com> (raw)
In-Reply-To: <CAJSP0QWoWf9An8=k3JZZv0xUUGWpZ8b898ZBiGZBdr5kyNBgPQ@mail.gmail.com>

Am 09.09.2011 15:54, schrieb Stefan Hajnoczi:
> On Fri, Sep 9, 2011 at 2:48 PM, Zhi Yong Wu <zwu.kernel@gmail.com> wrote:
>> On Fri, Sep 9, 2011 at 6:38 PM, Stefan Hajnoczi
>> <stefanha@linux.vnet.ibm.com> wrote:
>>> On Fri, Sep 09, 2011 at 05:44:36PM +0800, Zhi Yong Wu wrote:
>>>> Today, i did some basical I/O testing, and suddenly found that qemu write and rw speed is so low now, my qemu binary is built on commit 344eecf6995f4a0ad1d887cec922f6806f91a3f8.
>>>>
>>>> Do qemu have regression?
>>>>
>>>> The testing data is shown as below:
>>>>
>>>> 1.) write
>>>>
>>>> test: (g=0): rw=write, bs=512-512/512-512, ioengine=libaio, iodepth=1
>>>
>>> Please post your QEMU command-line.  If your -drive is using
>>> cache=writethrough then small writes are slow because they require the
>>> physical disk to write and then synchronize its write cache.  Typically
>>> cache=none is a good setting to use for local disks.
>> Now i can not access my workstation in the office.
>> -drive if=virtio,cache=none,file=xxxx
>>
>>>
>>> The block size of 512 bytes is too small.  Ext4 uses a 4 KB block size,
>>> so I think a 512 byte write from the guest could cause a 4 KB
>>> read-modify-write operation on the host filesystem.
>> You mean RCU? What is its work procedure? Can you explain in more
>> details if you are available?
> 
> If the host file system manages space in 4 KB blocks, then a 512 byte
> to an unallocated part of the file causes the file system to find 4 KB
> of free space for this data.  Since the write is only 512 bytes and
> does not cover the entire 4 KB region, the file system initializes the
> remaining 3.5 KB with zeros and writes out the full 4 KB block.
> 
> Now if a 512 byte write comes in for an allocated 4 KB block, then we
> need to read in the existing 4 KB, modify the 512 bytes in place, and
> write out the 4 KB block again.  This is read-modify-write.  In this
> worst-case scenario a 512 byte write turns into a 4 KB read followed
> by a 4 KB write.

But that should only happen with a 4k sector size, otherwise there's no
reason for RMW.

Kevin

  reply	other threads:[~2011-09-09 14:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09  9:44 [Qemu-devel] Why qemu write/rw speed is so low? Zhi Yong Wu
2011-09-09 10:38 ` Stefan Hajnoczi
2011-09-09 13:48   ` Zhi Yong Wu
2011-09-09 13:54     ` Stefan Hajnoczi
2011-09-09 14:04       ` Kevin Wolf [this message]
2011-09-09 15:27         ` Stefan Hajnoczi
2011-09-11 13:32         ` Christoph Hellwig
2011-09-09 14:09       ` Zhi Yong Wu
2011-09-13  2:38   ` Zhi Yong Wu
2011-09-13  2:52     ` Zhi Yong Wu
2011-09-13  7:14       ` Stefan Hajnoczi
2011-09-13  9:25         ` Zhi Yong Wu
2011-09-13 10:14           ` Stefan Hajnoczi
2011-09-13 10:27             ` Zhi Yong Wu
2011-09-14  2:42             ` Zhi Yong Wu
2011-09-14 14:17               ` Stefan Hajnoczi
2011-09-15  9:04                 ` Zhi Yong Wu
2011-09-13  7:15     ` Stefan Hajnoczi
2011-09-13  8:31       ` Zhi Yong Wu
2011-09-13  8:49         ` Stefan Hajnoczi
2011-09-13  8:54           ` Zhi Yong Wu

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=4E6A1CD7.70300@redhat.com \
    --to=kwolf@redhat.com \
    --cc=aliguro@us.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=ryanh@us.ibm.com \
    --cc=stefanha@gmail.com \
    --cc=stefanha@linux.vnet.ibm.com \
    --cc=wuzhy@linux.vnet.ibm.com \
    --cc=zwu.kernel@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.