qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH v5 0/2] block: enforce minimal 4096


From: Denis V. Lunev
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v5 0/2] block: enforce minimal 4096 alignment in qemu_blockalign
Date: Wed, 13 May 2015 19:46:57 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 13/05/15 18:43, Stefan Hajnoczi wrote:
On Tue, May 12, 2015 at 12:46:57PM +0200, Paolo Bonzini wrote:

On 12/05/2015 12:19, Denis V. Lunev wrote:

hades /vol $ strace -f -e pwrite -e raw=write,pwrite  qemu-io -n -c
"write -P 0x11 0 64M" ./1.img
Process 19326 attached
[pid 19326] pwrite(0x6, 0x7fac07fff200, 0x4000000, 0x50000) = 0x4000000
<---- 1 GB Write from userspace
FWIW this is 64 MB (as expected).

wrote 67108864/67108864 bytes at offset 0
64 MiB, 1 ops; 0.2964 sec (215.863 MiB/sec and 3.3729 ops/sec)
[pid 19326] +++ exited with 0 +++
+++ exited with 0 +++
hades /vol $
   9,0    1      266    74.030359772 19326  Q  WS 473095 + 1016 [(null)]
   9,0    1      267    74.030361546 19326  Q  WS 474111 + 8 [(null)]
   9,0    1      268    74.030395522 19326  Q  WS 474119 + 1016 [(null)]
   9,0    1      269    74.030397509 19326  Q  WS 475135 + 8 [(null)]

This means, yes, kernel is INEFFECTIVE performing direct IO with
not aligned address. For example, without direct IO the pattern is
much better.
I think this means that the kernel is DMAing at most 128 pages at a
time.  If the buffer is misaligned, you need 129 pages and the kernel
then splits the request into a 128 page and a 1 page part.

This looks like a hardware limit, and the kernel probably cannot really
do anything about it because we requested O_DIRECT.  So your patch makes
sense.
A 64 MB buffer was given in the pwrite() call.

The first and the last 128-page write requests may have partial pages,
but why should the rest not use fully aligned 1024 sector writes?

Maybe the buffer is split by the max sectors per request before the
alignment requirements are considered.  It would be more efficient to
first split off the unaligned parts.

So I think the kernel is still doing something suboptimal here.

Stefan
I agree with this. Kernel guys are aware and may be we will have
the fix after a while... I have heard (not tested) that performance
loss over multi-queue SSD is around 30%.

Den



reply via email to

[Prev in Thread] Current Thread [Next in Thread]