qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: aliguro@us.ibm.com, Stefan Hajnoczi <stefanha@gmail.com>,
	qemu-devel@nongnu.org, ryanh@us.ibm.com,
	Zhi Yong Wu <zwu.kernel@gmail.com>,
	Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] Why qemu write/rw speed is so low?
Date: Fri, 9 Sep 2011 16:27:22 +0100	[thread overview]
Message-ID: <20110909152722.GA29109@stefanha-thinkpad.localdomain> (raw)
In-Reply-To: <4E6A1CD7.70300@redhat.com>

On Fri, Sep 09, 2011 at 04:04:07PM +0200, Kevin Wolf wrote:
> 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.

You're right.  For cache=none (O_DIRECT), the host file system should
not need to do read-modify-write because it can write the single sector
without caring what is in the surrounding 3.5 KB.

Stefan

  reply	other threads:[~2011-09-09 15:27 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
2011-09-09 15:27         ` Stefan Hajnoczi [this message]
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=20110909152722.GA29109@stefanha-thinkpad.localdomain \
    --to=stefanha@linux.vnet.ibm.com \
    --cc=aliguro@us.ibm.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=ryanh@us.ibm.com \
    --cc=stefanha@gmail.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 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).