qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Denis V. Lunev" <den@openvz.org>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v5 0/2] block: enforce minimal 4096 alignment in qemu_blockalign
Date: Mon, 11 May 2015 19:07:17 +0300	[thread overview]
Message-ID: <5550D3B5.2050703@openvz.org> (raw)
In-Reply-To: <20150511150817.GK16270@stefanha-thinkpad.redhat.com>

On 11/05/15 18:08, Stefan Hajnoczi wrote:
> On Mon, May 04, 2015 at 04:42:22PM +0300, Denis V. Lunev wrote:
>> The difference is quite reliable and the same 5%.
>>    qemu-io -n -c 'write -P 0xaa 0 1G' 1.img
>> for image in qcow2 format is 1% faster.
> I looked a little at the qemu-io invocation but am not clear why there
> would be a measurable performance difference.  Can you explain?
>
> What about real qemu-img or QEMU use cases?
>
> I'm okay with the patches themselves, but I don't really understand why
> this code change is justified.
>
> Stefan
There is a problem in the Linux kernel when the buffer
is not aligned to the page size. Actually the strict requirement
is the alignment to the 512 (one physical sector).

This comes into the account in qemu-img and qemu-io
when buffers are allocated inside the application. QEMU
is free of this problem as the guest sends buffers
aligned to page already.

You can see below results of qemu-img, they are exactly
the same as for qemu-io.

qemu-img create -f qcow2 1.img 64G
qemu-io -n -c 'write -P 0xaa 0 1G' 1.img
time for i in `seq 1 30` ; do /home/den/src/qemu/qemu-img convert 1.img 
-t none -O raw 2.img ; rm -rf 2.img ; done

==== without patches ====:
real    2m6.287s
user    0m1.322s
sys    0m8.819s

real    2m7.483s
user    0m1.614s
sys    0m9.096s

==== with patches ====:
real    1m59.715s
user    0m1.453s
sys    0m9.365s

real    1m58.739s
user    0m1.419s
sys    0m8.530s

I could not exactly say where the difference comes, but
the problem comes from the fact that real IO operation
over the block device should be
   a) page aligned for the buffer
   b) page aligned for the offset
This is how buffer cache is working in the kernel. And
with non-aligned buffer in userspace the kernel should collect
kernel page for IO from 2 userspaces pages instead of one.
Something is not optimal here I presume. I can assume
that the user page could be sent immediately to the
controller is buffer is aligned and no additional memory
allocation is needed. Though I don't know exactly.

Regards,
     Den

  reply	other threads:[~2015-05-11 16:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04 13:42 [Qemu-devel] [PATCH v5 0/2] block: enforce minimal 4096 alignment in qemu_blockalign Denis V. Lunev
2015-05-04 13:42 ` [Qemu-devel] [PATCH 1/2] block: minimal bounce buffer alignment Denis V. Lunev
2015-05-04 13:42 ` [Qemu-devel] [PATCH 2/2] block: align bounce buffers to page Denis V. Lunev
2015-05-11 14:54   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-05-11 15:32     ` Eric Blake
2015-05-11 15:40       ` Denis V. Lunev
2015-05-11 15:08 ` [Qemu-devel] [Qemu-block] [PATCH v5 0/2] block: enforce minimal 4096 alignment in qemu_blockalign Stefan Hajnoczi
2015-05-11 16:07   ` Denis V. Lunev [this message]
2015-05-11 16:38     ` Denis V. Lunev
2015-05-11 16:47     ` Denis V. Lunev
2015-05-12 10:01       ` Stefan Hajnoczi
2015-05-12 10:19         ` Denis V. Lunev
2015-05-12 10:46           ` Paolo Bonzini
2015-05-13 15:43             ` Stefan Hajnoczi
2015-05-13 16:46               ` Denis V. Lunev
2015-05-29 16:43                 ` [Qemu-devel] " Paolo Bonzini
2015-06-01 10:34                   ` Dmitry Monakhov
2015-06-01 10:41                     ` Paolo Bonzini
2015-06-01 11:16                       ` Dmitry Monakhov
2015-06-01 11:26                         ` Paolo Bonzini
2015-06-01 11:57                           ` Dmitry Monakhov
2015-05-14  9:13               ` [Qemu-devel] [Qemu-block] " Paolo Bonzini

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=5550D3B5.2050703@openvz.org \
    --to=den@openvz.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --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).