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] Reducing I/O introduced domain scheduling

To: Keir Fraser <keir@xxxxxxx>
Subject: RE: [Xen-devel] Reducing I/O introduced domain scheduling
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Tue, 12 Oct 2010 15:19:45 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Tue, 12 Oct 2010 00:24:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8D9C0F4.25A56%keir@xxxxxxx>
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: <1A42CE6F5F474C41B63392A5F80372B22FECEE40@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C8D9C0F4.25A56%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Actpqn3hWuzhnq6kR7m69TDVjf/L0AALZYnDAAE9viA=
Thread-topic: [Xen-devel] Reducing I/O introduced domain scheduling
Keir Fraser wrote:
> On 12/10/2010 02:12, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:
>> Keir:
>> When running vConsolidation on top of Xen in  a 4-core platform, we
>> noticed the I/O introduced scheduling per CPU is ~3K Hz, which seems
>> to be too frequent and cause frequent involve of domain 0 / Qemu,
>> which may polute cache of the guest and thus increase CPI (cycle per
>> instruction). 
>> We are thinking if we can reduce the domin switch here, and think
>> the output of I/O can be buffered and return immediately. The
>> buffered I/O can be flushed out at next IN emulation (or any
>> Hypervisor emulated I/O) or timeout such as 10 or 100 us to
>> guarantee minimal response. 
>> Ideally it can cover both PIO & MMIO, but we can start from PIO.
>> How do you think of that?
> First of all have you tested with PV drivers? Performance tests with
> no PV drivers are not that interesting.

We used PV driver as more as possible, however the C disk in Windows guest 
doesn't support PV yet. (A task in BIOS side or Win HAL side?)

> Apart from that this sounds like a generalisation of the buffered-i/o
> mechanism we already have for svga emulation. I suppose it might be
> plausible.

It is generic, similar to SVGA, but the timeout in generic I/O may be much 
smaller than display stuff, if a guest is waiting for an interrupt after 
several OUT instruction.

>  -- Keir

Thx, Eddie
Xen-devel mailing list