From: Kevin Wolf <kwolf@redhat.com>
To: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com,
armbru@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 03/19] block: Don't use guest sector size for qemu_blockalign()
Date: Tue, 10 Dec 2013 10:42:14 +0100 [thread overview]
Message-ID: <20131210094214.GB3656@dhcp-200-207.str.redhat.com> (raw)
In-Reply-To: <52A687F8.8000205@linux.vnet.ibm.com>
Am 10.12.2013 um 04:18 hat Wenchao Xia geschrieben:
> 于 2013/12/7 1:22, Kevin Wolf 写道:
> > bs->buffer_alignment is set by the device emulation and contains the
> > logical block size of the guest device. This isn't something that the
> > block layer should know, and even less something to use for determining
> > the right alignment of buffers to be used for the host.
> >
> > The new function bdrv_opt_mem_align() allows for hooks in a BlockDriver
> > so that it can tell the qemu block layer the optimal alignment to be
> > used so that no bounce buffer must be used in the driver.
> >
> > This patch may change the buffer alignment from 4k to 512 for all
> > callers that used qemu_blockalign() with the top-level image format
> > BlockDriverState. The value was never propagated to other levels in the
> > tree, so in particular raw-posix never required anything else than 512.
> >
> > While on disks with 4k sectors direct I/O requires a 4k alignment,
> > memory may still be okay when aligned to 512 byte boundaries. This is
> > what must have happened in practice, because otherwise this would
> > already have failed earlier. Therefore I don't expect regressions even
> > with this intermediate state. Later, raw-posix can implement the hook
> > and expose a different memory alignment requirement.
> >
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> > block.c | 32 +++++++++++++++++++++++++++++---
> > include/block/block.h | 1 +
> > include/block/block_int.h | 4 ++++
> > 3 files changed, 34 insertions(+), 3 deletions(-)
> >
> > diff --git a/block.c b/block.c
> > index 613201b..669793b 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -213,6 +213,31 @@ static void bdrv_io_limits_intercept(BlockDriverState *bs,
> > qemu_co_queue_next(&bs->throttled_reqs[is_write]);
> > }
> >
> > +size_t bdrv_opt_mem_align(BlockDriverState *bs)
> > +{
> > + size_t alignment;
> > +
> > + if (!bs || !bs->drv) {
> > + /* 4k should be on the safe side */
> > + return 4096;
> > + }
> > +
> > + if (bs->drv->bdrv_opt_mem_align) {
> > + return bs->drv->bdrv_opt_mem_align(bs);
> > + }
> > +
> > + if (bs->file) {
> > + alignment = bdrv_opt_mem_align(bs->file);
> > + } else {
> > + alignment = 512;
> > + }
> > +
> > + if (bs->backing_hd) {
> > + alignment = MAX(alignment, bdrv_opt_mem_align(bs->backing_hd));
> > + }
>
> Maybe I didn't understand the commit message correctly, does this code
> intend to get MAX alignment value in a chain? For example:
> base(4096)->mid(512)->top(1024) results: 4096
> The condition to traver the backing files seems complex.
Yes, you want to align any newly allocated buffer such that no matter
what direction it takes on its way through the block layer, it will
never be misaligned. This means that you need to use the highest
alignment restriction.
Kevin
next prev parent reply other threads:[~2013-12-10 9:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 17:22 [Qemu-devel] [RFC PATCH 00/19] block: Support for 512b-on-4k emulation Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 01/19] qemu_memalign: Allow small alignments Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 02/19] block: Detect unaligned length in bdrv_qiov_is_aligned() Kevin Wolf
2013-12-06 19:12 ` Eric Blake
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 03/19] block: Don't use guest sector size for qemu_blockalign() Kevin Wolf
2013-12-10 3:18 ` Wenchao Xia
2013-12-10 9:42 ` Kevin Wolf [this message]
2013-12-11 2:43 ` Wenchao Xia
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 04/19] block: rename buffer_alignment to guest_block_size Kevin Wolf
2013-12-10 3:25 ` Wenchao Xia
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 05/19] raw: Probe required direct I/O alignment Kevin Wolf
2013-12-06 17:53 ` Paolo Bonzini
2013-12-09 12:58 ` Kevin Wolf
2013-12-09 13:40 ` Paolo Bonzini
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 06/19] block: Introduce bdrv_aligned_preadv() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 07/19] block: Introduce bdrv_co_do_preadv() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 08/19] block: Introduce bdrv_aligned_pwritev() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 09/19] block: write: Handle COR dependency after I/O throttling Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 10/19] block: Introduce bdrv_co_do_pwritev() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 11/19] block: Switch BdrvTrackedRequest to byte granularity Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 12/19] block: Allow waiting for overlapping requests between begin/end Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 13/19] block: Make zero-after-EOF work with larger alignment Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 14/19] block: Generalise and optimise COR serialisation Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 15/19] block: Make overlap range for serialisation dynamic Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 16/19] block: Align requests in bdrv_co_do_pwritev() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 17/19] block: Change coroutine wrapper to byte granularity Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 18/19] block: Make bdrv_pread() a bdrv_prwv_co() wrapper Kevin Wolf
2013-12-06 17:23 ` [Qemu-devel] [RFC PATCH 19/19] block: Make bdrv_pwrite() " Kevin Wolf
2013-12-06 17:55 ` [Qemu-devel] [RFC PATCH 00/19] block: Support for 512b-on-4k emulation Paolo Bonzini
2013-12-09 11:16 ` Kevin Wolf
2013-12-09 12:51 ` Stefan Hajnoczi
2013-12-09 13:02 ` 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=20131210094214.GB3656@dhcp-200-207.str.redhat.com \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=xiawenc@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).