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

["Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>]

Keir Fraser wrote:
> On 21/01/2010 09:27, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>
> > > 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.
> How does the attached patch work for you? It ought to get you the same
> speedup as your hack.
The speed should be almost the same, regardless of twice memcpy.

Some comments to your trial patch:
1.
diff -r 6b61ef936e69 tools/libxc/xc_private.c
--- a/tools/libxc/xc_private.c  Fri Jan 22 14:50:30 2010 +0800
+++ b/tools/libxc/xc_private.c  Fri Jan 22 15:32:48 2010 +0800
@@ -188,7 +188,10 @@
          ((hcall_buf = calloc(1, sizeof(*hcall_buf))) != NULL) )
         pthread_setspecific(hcall_buf_pkey, hcall_buf);
     if ( hcall_buf->buf == NULL )
+    {
         hcall_buf->buf = xc_memalign(PAGE_SIZE, PAGE_SIZE);
+        lock_pages(hcall_buf->buf, PAGE_SIZE);
+    }

     if ( (len < PAGE_SIZE) && hcall_buf && hcall_buf->buf &&
          !hcall_buf->oldbuf )


2. _xc_clean_hcall_buf needs a more careful NULL pointer check.

3. It does modification to 5 out of 73 hypercalls invoking mlock. Other problem 
hypercalls could turn out to be the bottleneck later?:)
Thanks,
xiaowei

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