This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[RE-PATCH] Re: [Xen-devel] [PATCH] blkback: Fix block I/O latency issue

To: "Vincent, Pradeep" <pradeepv@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [RE-PATCH] Re: [Xen-devel] [PATCH] blkback: Fix block I/O latency issue
From: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Date: Sat, 28 May 2011 13:12:27 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 30 May 2011 06:46:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9E3A578.12B8E%pradeepv@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix VMD
References: <C9E3A578.12B8E%pradeepv@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

I got a chance to look into the problem below while chasing after some
issues with big ring support.  The way the blkback request dispatching
presently works is indeed critically retarded.

What the present approach essentially does is blocking any further
request processing until the previously observed batch starts to
complete. This completely kills throughput in the very common case where
guests unplug or notify early, while rightfully assuming the reminder of
their batch will be picked up as timely as the initial one.

Proposed solution is to render request consumption and response
production independent, as usual.

Without having worked my way through the remainder of this thread again,
the original goes into the right direction, but I think it should
distinguish more between more_to_do -> we got more requests, go for
them, and more_to_do -> we got more requests, but we're resource
congested, so wait().

Remaining request related processing in make_response is garbage, so

Patch follows and I'd strongly recommend to apply this or a similar fix
to any tree under maintenance too.


On Mon, 2011-05-02 at 03:04 -0400, Vincent, Pradeep wrote:
> In blkback driver, after I/O requests are submitted to Dom-0 block I/O 
> subsystem, blkback goes to 'sleep' effectively without letting blkfront know 
> about it (req_event isn't set appropriately). Hence blkfront doesn't notify 
> blkback when it submits a new I/O thus delaying the 'dispatch' of the new I/O 
> to Dom-0 block I/O subsystem. The new I/O is dispatched as soon as one of the 
> previous I/Os completes.
> As a result of this issue, the block I/O latency performance is degraded for 
> some workloads on Xen guests using blkfront-blkback stack.
> The following change addresses this issue:
> Signed-off-by: Pradeep Vincent <pradeepv@xxxxxxxxxx>
> diff --git a/drivers/xen/blkback/blkback.c b/drivers/xen/blkback/blkback.c
> --- a/drivers/xen/blkback/blkback.c
> +++ b/drivers/xen/blkback/blkback.c
> @@ -383,6 +383,12 @@ static int do_block_io_op(blkif_t *blkif)
>   cond_resched();
>   }
> + /* If blkback might go to sleep (i.e. more_to_do == 0) then we better
> +   let blkfront know about it (by setting req_event appropriately) so that
> +   blkfront will bother to wake us up (via interrupt) when it submits a
> +   new I/O */
> +        if (!more_to_do)
> +                 RING_FINAL_CHECK_FOR_REQUESTS(&blk_rings->common, 
> more_to_do);
>   return more_to_do;
>  }

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>