All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk
Date: Fri, 26 Nov 2010 12:03:35 +0100	[thread overview]
Message-ID: <4CEF9407.80706@redhat.com> (raw)
In-Reply-To: <20101124184405.GA2406@lst.de>

Am 24.11.2010 19:44, schrieb Christoph Hellwig:
> On Wed, Nov 24, 2010 at 10:18:40AM -0800, Jeremy Fitzhardinge wrote:
>> Linux wants is a useful thing to do and implement (especially since it
>> amounts to standardising the ?BSD extension).  I'm not sure of their
>> precise semantics (esp WRT ordering), but I think its already OK.
> 
> The nice bit is that a pure flush does not imply any odering at all.
> Which is how the current qemu driver implements the barrier requests
> anyway, so that needs some fixing.
> 
>> (BTW, in case it wasn't clear, we're seriously considering - but not yet
>> committed to - using qemu as the primary PV block backend for Xen
>> instead of submitting the existing blkback code for upstream.  We still
>> need to do some proper testing and measuring to make sure it stacks up
>> OK, and work out how it would fit together with the rest of the
>> management stack.  But so far it looks promising.)
> 
> Good to know.  Besides the issue with barriers mentioned above there's
> a few things that need addressing in xen_disk, if you (or Stefano or
> Daniel) are interested:
> 
>  - remove the syncwrite tunable, as this is handled by the underlying
>    posix I/O code if needed by using O_DSYNC which is a lot more
>    efficient.
>  - check whatever the issue with the use_aio codepath is and make it
>    the default.  It should help the performance a lot.
>  - Make sure to use bdrv_aio_flush for cache flushes in the aio
>    codepath, currently it still uses plain synchronous flushes.

I don't think the synchronous flushes even do what they're supposed to
do. Shouldn't ioreq->postsync do the flush after the request has
completed instead of doing it as soon as it has been submitted?

Let alone that, as you mentioned above, it doesn't implement barrier
semantics at all.

Oh, and it would be very nice if the return values of
bdrv_aio_readv/writev and bdrv_flush were checked. They can return errors.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Wolf <kwolf@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk
Date: Fri, 26 Nov 2010 12:03:35 +0100	[thread overview]
Message-ID: <4CEF9407.80706@redhat.com> (raw)
In-Reply-To: <20101124184405.GA2406@lst.de>

Am 24.11.2010 19:44, schrieb Christoph Hellwig:
> On Wed, Nov 24, 2010 at 10:18:40AM -0800, Jeremy Fitzhardinge wrote:
>> Linux wants is a useful thing to do and implement (especially since it
>> amounts to standardising the ?BSD extension).  I'm not sure of their
>> precise semantics (esp WRT ordering), but I think its already OK.
> 
> The nice bit is that a pure flush does not imply any odering at all.
> Which is how the current qemu driver implements the barrier requests
> anyway, so that needs some fixing.
> 
>> (BTW, in case it wasn't clear, we're seriously considering - but not yet
>> committed to - using qemu as the primary PV block backend for Xen
>> instead of submitting the existing blkback code for upstream.  We still
>> need to do some proper testing and measuring to make sure it stacks up
>> OK, and work out how it would fit together with the rest of the
>> management stack.  But so far it looks promising.)
> 
> Good to know.  Besides the issue with barriers mentioned above there's
> a few things that need addressing in xen_disk, if you (or Stefano or
> Daniel) are interested:
> 
>  - remove the syncwrite tunable, as this is handled by the underlying
>    posix I/O code if needed by using O_DSYNC which is a lot more
>    efficient.
>  - check whatever the issue with the use_aio codepath is and make it
>    the default.  It should help the performance a lot.
>  - Make sure to use bdrv_aio_flush for cache flushes in the aio
>    codepath, currently it still uses plain synchronous flushes.

I don't think the synchronous flushes even do what they're supposed to
do. Shouldn't ioreq->postsync do the flush after the request has
completed instead of doing it as soon as it has been submitted?

Let alone that, as you mentioned above, it doesn't implement barrier
semantics at all.

Oh, and it would be very nice if the return values of
bdrv_aio_readv/writev and bdrv_flush were checked. They can return errors.

Kevin

  parent reply	other threads:[~2010-11-26 13:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-24 13:08 [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk Stefano Stabellini
2010-11-24 13:08 ` Stefano Stabellini
2010-11-24 14:23 ` [Qemu-devel] " Gerd Hoffmann
2010-11-24 16:29   ` Kevin Wolf
2010-11-24 16:46     ` Stefano Stabellini
2010-12-14 18:43   ` [Xen-devel] " Ian Jackson
2010-12-14 18:43     ` Ian Jackson
2010-11-24 16:58 ` Christoph Hellwig
2010-11-24 18:18   ` [Xen-devel] " Jeremy Fitzhardinge
2010-11-24 18:18     ` Jeremy Fitzhardinge
2010-11-24 18:44     ` [Xen-devel] " Christoph Hellwig
2010-11-24 18:44       ` Christoph Hellwig
2010-11-24 19:55       ` [Xen-devel] " Stefano Stabellini
2010-11-24 19:55         ` Stefano Stabellini
2010-11-26 11:03       ` Kevin Wolf [this message]
2010-11-26 11:03         ` Kevin Wolf
2010-11-26 13:29         ` [Xen-devel] " Christoph Hellwig
2010-11-26 13:29           ` Christoph Hellwig
2010-11-26 15:25         ` [Xen-devel] " Stefano Stabellini
2010-11-26 15:25           ` Stefano Stabellini
     [not found]     ` <m2n.s.1PLKM9-000VR4@chiark.greenend.org.uk>
2010-11-25 19:30       ` [Xen-devel] " Ian Jackson
2010-11-25 19:30         ` Ian Jackson
2010-11-25 19:46         ` [Xen-devel] " Jeremy Fitzhardinge
2010-11-25 19:46           ` Jeremy Fitzhardinge
2010-11-25 23:30           ` [Xen-devel] " Christoph Hellwig
2010-11-25 23:30             ` Christoph Hellwig

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=4CEF9407.80706@redhat.com \
    --to=kwolf@redhat.com \
    --cc=hch@lst.de \
    --cc=jeremy@goop.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.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.