All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 6/8] block: request overlap detection
Date: Tue, 22 Nov 2011 17:36:19 +0100	[thread overview]
Message-ID: <4ECBCF83.6090701@redhat.com> (raw)
In-Reply-To: <CAJSP0QW5PAPh7Ormpa_7ZoR6WhG8LFYkiw7HVrMe__7mRJ+=uw@mail.gmail.com>

Am 22.11.2011 16:10, schrieb Stefan Hajnoczi:
> On Tue, Nov 22, 2011 at 3:06 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 17.11.2011 14:40, schrieb Stefan Hajnoczi:
>>> Detect overlapping requests and remember to align to cluster boundaries
>>> if the image format uses them.  This assumes that allocating I/O is
>>> performed in cluster granularity - which is true for qcow2, qed, etc.
>>>
>>> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>>
>>>  static void coroutine_fn wait_for_overlapping_requests(BlockDriverState *bs,
>>>          int64_t sector_num, int nb_sectors)
>>>  {
>>>      BdrvTrackedRequest *req;
>>> +    int64_t cluster_sector_num;
>>> +    int cluster_nb_sectors;
>>>      bool retry;
>>>
>>> +    /* If we touch the same cluster it counts as an overlap */
>>> +    round_to_clusters(bs, sector_num, nb_sectors,
>>> +                      &cluster_sector_num, &cluster_nb_sectors);
>>
>> Is this really required? Image formats must be able to deal with two
>> concurrent write requests to the same cluster, and I don't think it
>> makes a difference whether it's a guest write request or a COR one.
>>
>> Or does the queuing protect more than just that a COR never takes
>> precedence over a guest write?
> 
> It guarantees that a write request and a copy-on-read request racing
> for the same cluster will be serialized.  Either:
> 1. CoR, then write.
> 2. Allocating write, then normal read.
> 
> If we don't do this we risk:
> 3. CoR (part 1: read), allocating write, CoR (part 2: write)
> 
> The result is that we dropped the write request!

Right, this requirement comes in with the next patch that makes COR
round clusters for optimisation. I think this relationship deserves a
comment here.

Anyway, I merged the series into the block branch (Only to notice that
it would have been better to merge bdrv_co_is_allocated first... Will
review that tomorrow.) If you send another version for this patch to add
a comment, I'll replace it.

Kevin

  reply	other threads:[~2011-11-22 16:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17 13:40 [Qemu-devel] [PATCH v2 0/8] block: generic copy-on-read Stefan Hajnoczi
2011-11-17 13:40 ` [Qemu-devel] [PATCH v2 1/8] qemu-common: add QEMU_ALIGN_DOWN() and QEMU_ALIGN_UP() macros Stefan Hajnoczi
2011-11-17 13:40 ` [Qemu-devel] [PATCH v2 2/8] coroutine: add qemu_co_queue_restart_all() Stefan Hajnoczi
2011-11-17 13:40 ` [Qemu-devel] [PATCH v2 3/8] block: add request tracking Stefan Hajnoczi
2011-11-17 13:40 ` [Qemu-devel] [PATCH v2 4/8] block: add bdrv_set_copy_on_read() Stefan Hajnoczi
2011-11-17 13:40 ` [Qemu-devel] [PATCH v2 5/8] block: wait for overlapping requests Stefan Hajnoczi
2011-11-17 13:43   ` Paolo Bonzini
2011-11-17 13:51     ` Stefan Hajnoczi
2011-11-17 13:40 ` [Qemu-devel] [PATCH v2 6/8] block: request overlap detection Stefan Hajnoczi
2011-11-22 15:06   ` Kevin Wolf
2011-11-22 15:10     ` Stefan Hajnoczi
2011-11-22 16:36       ` Kevin Wolf [this message]
2011-11-17 13:40 ` [Qemu-devel] [PATCH v2 7/8] block: core copy-on-read logic Stefan Hajnoczi
2011-11-23  3:42   ` Zhi Yong Wu
2011-11-23  9:05     ` Stefan Hajnoczi
2011-11-23  9:51       ` Zhi Yong Wu
2011-11-23  4:42   ` Zhi Yong Wu
2011-11-23  8:58     ` Stefan Hajnoczi
2011-11-23  9:00       ` Stefan Hajnoczi
2011-11-17 13:40 ` [Qemu-devel] [PATCH v2 8/8] block: add -drive copy-on-read=on|off Stefan Hajnoczi

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=4ECBCF83.6090701@redhat.com \
    --to=kwolf@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@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 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.