WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Root cause of the issue that HVM guest boots slowly with

To: "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Root cause of the issue that HVM guest boots slowly with pvops dom0
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 21 Jan 2010 09:27:51 +0000
Cc:
Delivery-date: Thu, 21 Jan 2010 01:28:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C77DC471.6ED6%keir.fraser@xxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqacmPuu1wkaW3ARrGtHNq5b+C1qAAA5Ag8AAGDIjw=
Thread-topic: [Xen-devel] Root cause of the issue that HVM guest boots slowly with pvops dom0
User-agent: Microsoft-Entourage/12.23.0.091001
On 21/01/2010 08:44, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

>> - Limiting vCPU# of dom0 is always an easiest one - you may call it
>> workaround
>> rather than a solution:) It not only reduces the total # of resched IPI ( =
>> mlock# * (vCPU#-1)), but reduces the cost of each handler - because of
>> spinlock. 
>> But the impact is still there, more or less, when vCPU# > 1.
>> 
>> - To remove mlock, another sharing method is needed between dom0 user space
>> app
>> and Xen HV.
> 
> A pre-mlock()ed memory page for small (sub-page) hypercalls? Protected with
> a semaphore: failure to acquire semaphore means take slow path. Have all
> hypercallers in libxc launder their data buffers through a new interface
> that tries to grab and copy into the pre-allocated buffer.

I'll sort out a trial patch for this myself.

 Thanks,
 Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel