From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Vincent, Pradeep" Subject: [PATCH] blkback: Fix block I/O latency issue Date: Mon, 2 May 2011 00:04:09 -0700 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_004_C9E3A57812B8Epradeepvamazoncom_" Return-path: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org --_004_C9E3A57812B8Epradeepvamazoncom_ Content-Type: multipart/alternative; boundary="_000_C9E3A57812B8Epradeepvamazoncom_" --_000_C9E3A57812B8Epradeepvamazoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In blkback driver, after I/O requests are submitted to Dom-0 block I/O subs= ystem, blkback goes to 'sleep' effectively without letting blkfront know ab= out it (req_event isn't set appropriately). Hence blkfront doesn't notify b= lkback 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 fo= r some workloads on Xen guests using blkfront-blkback stack. The following change addresses this issue: Signed-off-by: Pradeep Vincent 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 =3D=3D 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; } --_000_C9E3A57812B8Epradeepvamazoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 sub= system. The new I/O is dispatched as soon as one of the previous I/Os compl= etes.

As a result of this issue, the block I/O lat= ency performance is degraded for some workloads on Xen guests using blkfron= t-blkback stack.

The following change addresses th= is issue:

Signed-off-by: Prade= ep Vincent <pradeepv@amazon.com>

diff --git = a/drivers/xen/blkback/blkback.c b/drivers/xen/blkback/blkback.c

-= -- a/drivers/xen/blkback/blkback.c

+++ b/drivers/xen/blkback/blkb= ack.c

@@ -383,6 +383,12 @@ static int do_block_io_op(blkif_t *blk= if)

cond_resched();

}

+ /* If blkback might g= o to sleep (i.e. more_to_do =3D=3D 0) then we better

+ let blkfront = know about it (by setting req_event appropriately) so that

+ blkfron= t will bother to wake us up (via interrupt) when it submits a

+ = ; new I/O */

+ if (!more_to_do)

<= div>+ RING_FINAL_CH= ECK_FOR_REQUESTS(&blk_rings->common, more_to_do);

return more_= to_do;

}

--_000_C9E3A57812B8Epradeepvamazoncom_-- --_004_C9E3A57812B8Epradeepvamazoncom_ Content-Type: application/octet-stream; name="blkback-bugfix-reqevent-assignment.patch" Content-Description: blkback-bugfix-reqevent-assignment.patch Content-Disposition: attachment; filename="blkback-bugfix-reqevent-assignment.patch"; size=662; creation-date="Mon, 02 May 2011 07:04:11 GMT"; modification-date="Mon, 02 May 2011 07:04:11 GMT" Content-Transfer-Encoding: base64 U2lnbmVkLW9mZi1ieTogUHJhZGVlcCBWaW5jZW50IDxwcmFkZWVwdkBhbWF6b24uY29tPgoKZGlm ZiAtLWdpdCBhL2RyaXZlcnMveGVuL2Jsa2JhY2svYmxrYmFjay5jIGIvZHJpdmVycy94ZW4vYmxr YmFjay9ibGtiYWNrLmMKLS0tIGEvZHJpdmVycy94ZW4vYmxrYmFjay9ibGtiYWNrLmMKKysrIGIv ZHJpdmVycy94ZW4vYmxrYmFjay9ibGtiYWNrLmMKQEAgLTM4Myw2ICszODMsMTIgQEAgc3RhdGlj IGludCBkb19ibG9ja19pb19vcChibGtpZl90ICpibGtpZikKIAkJY29uZF9yZXNjaGVkKCk7CiAJ fQogCisJLyogSWYgYmxrYmFjayBtaWdodCBnbyB0byBzbGVlcCAoaS5lLiBtb3JlX3RvX2RvID09 IDApIHRoZW4gd2UgYmV0dGVyCisJICAgbGV0IGJsa2Zyb250IGtub3cgYWJvdXQgaXQgKGJ5IHNl dHRpbmcgcmVxX2V2ZW50IGFwcHJvcHJpYXRlbHkpIHNvIHRoYXQKKwkgICBibGtmcm9udCB3aWxs IGJvdGhlciB0byB3YWtlIHVzIHVwICh2aWEgaW50ZXJydXB0KSB3aGVuIGl0IHN1Ym1pdHMgYSAK KwkgICBuZXcgSS9PICovCisgICAgICAgIGlmICghbW9yZV90b19kbykKKyAgICAgICAgICAgICAg ICAgUklOR19GSU5BTF9DSEVDS19GT1JfUkVRVUVTVFMoJmJsa19yaW5ncy0+Y29tbW9uLCBtb3Jl X3RvX2RvKTsKIAlyZXR1cm4gbW9yZV90b19kbzsKIH0KIAo= --_004_C9E3A57812B8Epradeepvamazoncom_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --_004_C9E3A57812B8Epradeepvamazoncom_--