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: [Xen-devel] [PATCH] blkback: Fix block I/O latency issue

To: "Vincent, Pradeep" <pradeepv@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] blkback: Fix block I/O latency issue
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 9 May 2011 16:24:03 -0400
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Delivery-date: Mon, 09 May 2011 13:25:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9E5A81B.1376F%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>
References: <1304445176.22480.120.camel@xxxxxxxxxxxxxxxxxxxxxxx> <C9E5A81B.1376F%pradeepv@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, May 03, 2011 at 06:54:38PM -0700, Vincent, Pradeep wrote:
> Hey Daniel,
> Thanks for your comments.
> >> The notification avoidance these macros implement does not promote
> >>deliberate latency. This stuff is not dropping events or deferring guest
> requests.
> It only avoids a gratuitious notification sent by the remote end in
> cases where the local one didn't go to sleep yet, and therefore can
> >>guarantee that it's going to process the message ASAP, right after
> >>finishing what's still pending from the previous kick.
> If the design goal was to simply avoid unnecessary interrupts but not
> delay I/Os, then blkback code has a bug.
> If the design goal was to delay the I/Os in order to reducing interrupt
> rate, then I am arguing that the design introduces way too much latency
> that affects many applications.
> Either way, this issue needs to be addressed.

I agree we need to fix this. What I am curious is:
 - what are the workloads under which this patch has a negative effect.
 - I presume you have tested this in the production - what were the numbers
   when it came to high bandwith numbers (so imagine, four or six threads
   putting as much I/O as possible)? Did the level of IRQs go way up
   compared to not running with this patch?

I am wondering if it might be worth looking in something NAPI-type in the
block layer (so polling basically). The concern I've is that this
patch would trigger a interrupt storm for small sized requests which might be
happening at a high rate (say, 512 bytes random writes).

But perhaps the way for this work is to have a ratelimiting code in it
so that there is no chance of interrupt storms.

Xen-devel mailing list

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