qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC 1/6] block: add request tracking
Date: Wed, 02 Nov 2011 17:30:10 +0100	[thread overview]
Message-ID: <4EB17012.1020409@redhat.com> (raw)
In-Reply-To: <1318866452-30026-2-git-send-email-stefanha@linux.vnet.ibm.com>

Am 17.10.2011 17:47, schrieb Stefan Hajnoczi:
> The block layer does not know about pending requests.  This information
> is necessary for copy-on-read since overlapping requests must be
> serialized to prevent races that corrupt the image.
> 
> Add a simple mechanism to enable/disable request tracking.  By default
> request tracking is disabled.
> 
> The BlockDriverState gets a new tracked_request list field which
> contains all pending requests.  Each request is a BdrvTrackedRequest
> record with sector_num, nb_sectors, and is_write fields.
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
> ---
>  block.c     |   83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  block_int.h |    8 +++++
>  2 files changed, 90 insertions(+), 1 deletions(-)
> 
> diff --git a/block.c b/block.c
> index 9873b57..2d2c62a 100644
> --- a/block.c
> +++ b/block.c
> @@ -978,6 +978,77 @@ void bdrv_commit_all(void)
>      }
>  }
>  
> +struct BdrvTrackedRequest {
> +    BlockDriverState *bs;
> +    int64_t sector_num;
> +    int nb_sectors;
> +    bool is_write;
> +    QLIST_ENTRY(BdrvTrackedRequest) list;
> +};
> +
> +/**
> + * Remove an active request from the tracked requests list
> + *
> + * If req is NULL, no operation is performed.
> + *
> + * This function should be called when a tracked request is completing.
> + */
> +static void tracked_request_remove(BdrvTrackedRequest *req)
> +{
> +    if (req) {
> +        QLIST_REMOVE(req, list);
> +        g_free(req);
> +    }
> +}
> +
> +/**
> + * Add an active request to the tracked requests list
> + *
> + * Return NULL if request tracking is disabled, non-NULL otherwise.
> + */
> +static BdrvTrackedRequest *tracked_request_add(BlockDriverState *bs,
> +                                               int64_t sector_num,
> +                                               int nb_sectors, bool is_write)
> +{
> +    BdrvTrackedRequest *req;
> +
> +    if (!bs->request_tracking) {
> +        return NULL;
> +    }
> +
> +    req = g_malloc(sizeof(*req));
> +    req->bs = bs;
> +    req->sector_num = sector_num;
> +    req->nb_sectors = nb_sectors;
> +    req->is_write = is_write;

How about using g_malloc0 or a compound literal assignment for
initialisation, so that we won't get surprises when the struct is extended?

> +
> +    QLIST_INSERT_HEAD(&bs->tracked_requests, req, list);
> +
> +    return req;
> +}
> +
> +/**
> + * Enable tracking of incoming requests
> + *
> + * Request tracking can be safely used by multiple users at the same time,
> + * there is an internal reference count to match start and stop calls.
> + */
> +void bdrv_start_request_tracking(BlockDriverState *bs)
> +{
> +    bs->request_tracking++;
> +}
> +
> +/**
> + * Disable tracking of incoming requests
> + *
> + * Note that in-flight requests are still tracked, this function only stops
> + * tracking incoming requests.
> + */
> +void bdrv_stop_request_tracking(BlockDriverState *bs)
> +{
> +    bs->request_tracking--;
> +}
> +
>  /*
>   * Return values:
>   * 0        - success
> @@ -1262,6 +1333,8 @@ static int coroutine_fn bdrv_co_do_readv(BlockDriverState *bs,
>      int64_t sector_num, int nb_sectors, QEMUIOVector *qiov)
>  {
>      BlockDriver *drv = bs->drv;
> +    BdrvTrackedRequest *req;
> +    int ret;
>  
>      if (!drv) {
>          return -ENOMEDIUM;
> @@ -1270,7 +1343,10 @@ static int coroutine_fn bdrv_co_do_readv(BlockDriverState *bs,
>          return -EIO;
>      }
>  
> -    return drv->bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
> +    req = tracked_request_add(bs, sector_num, nb_sectors, false);
> +    ret = drv->bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
> +    tracked_request_remove(req);

Hm... Do we actually need to malloc the BdrvTrackedRequest? If all users
are like this (and at least those in this patch are), we can just keep
it on the coroutine stack.

Kevin

  reply	other threads:[~2011-11-02 16:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-17 15:47 [Qemu-devel] [RFC 0/6] block: generic copy-on-read Stefan Hajnoczi
2011-10-17 15:47 ` [Qemu-devel] [RFC 1/6] block: add request tracking Stefan Hajnoczi
2011-11-02 16:30   ` Kevin Wolf [this message]
2011-11-03  7:57     ` Stefan Hajnoczi
2011-11-07 11:00   ` Zhi Yong Wu
2011-11-07 11:41     ` Stefan Hajnoczi
2011-11-08  6:13       ` Zhi Yong Wu
2011-10-17 15:47 ` [Qemu-devel] [RFC 2/6] block: add bdrv_set_copy_on_read() Stefan Hajnoczi
2011-11-02 16:36   ` Kevin Wolf
2011-11-03  8:01     ` Stefan Hajnoczi
2011-10-17 15:47 ` [Qemu-devel] [RFC 3/6] block: wait for overlapping requests Stefan Hajnoczi
2011-10-18 13:48   ` Marcelo Tosatti
2011-10-20 17:34     ` Stefan Hajnoczi
2011-11-03 14:17   ` Kevin Wolf
2011-10-17 15:47 ` [Qemu-devel] [RFC 4/6] block: request overlap detection Stefan Hajnoczi
2011-11-07 11:49   ` Zhi Yong Wu
2011-11-07 14:37     ` Stefan Hajnoczi
2011-11-08  6:34       ` Zhi Yong Wu
2011-11-08  8:16         ` Stefan Hajnoczi
2011-11-08  9:49           ` Zhi Yong Wu
2011-10-17 15:47 ` [Qemu-devel] [RFC 5/6] block: core copy-on-read logic Stefan Hajnoczi
2011-10-18 14:00   ` Marcelo Tosatti
2011-10-20 17:40     ` Stefan Hajnoczi
2011-10-18 14:03   ` Marcelo Tosatti
2011-11-03 14:30   ` Kevin Wolf
2011-10-17 15:47 ` [Qemu-devel] [RFC 6/6] block: add -drive copy-on-read=on|off Stefan Hajnoczi
2011-11-03 14:32   ` Kevin Wolf
2011-11-03 16:21     ` Stefan Hajnoczi
2011-11-01 14:28 ` [Qemu-devel] [RFC 0/6] block: generic copy-on-read Stefan Hajnoczi
2011-11-01 15:07   ` Marcelo Tosatti

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=4EB17012.1020409@redhat.com \
    --to=kwolf@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --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 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).