[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] Performance of xen hosts with and without Virtualization Technology (VT) or AMD Virtualization


  • To: "Joop Boonen" <joop_boonen@xxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Tue, 25 Jul 2006 13:31:28 +0200
  • Delivery-date: Tue, 25 Jul 2006 04:32:28 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcaswlJFaP5/OcTnTi6JhNPRo36KPADGdF3w
  • Thread-topic: [Xen-users] Performance of xen hosts with and without Virtualization Technology (VT) or AMD Virtualization

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Joop Boonen
> Sent: 21 July 2006 13:36
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-users] Performance of xen hosts with and 
> without Virtualization Technology (VT) or AMD Virtualization
> 
> All,
> 
> I'm currious how the performance chart looks like what using 
> xen  with a
> xen aware kernel. On a CPU with and without Virtualization 
> Technology (VT)
> or AMD Virtualization.

At the moment, para-virtualized guests do not use AMDV/VT technology, so
there shouldn't be any difference other than what differences there are
in the processor itself [for example, DDR vs. DDR2 in AMD processors may
make some particular operation faster or slower - in AMD processors
there shouldn't be any performance difference in regular instructions -
some very rare operations may run one cycle or so slower, but I can
certainly say that for average code, the cycle-count is exactly
identical for older and new processors - I haven't tried to figure out
which, if any, of the obscure/system instructions have changed). 

> 
> I have afeeling that it doesn't effect the speed at all. Am i wrong?
> 
> Does Virtualization Technology (VT) or AMD Virtualization have any
> advantages for xen aware oses?

It is theoretically possible to cherry-pick functions in AMDV/VMX that
will improve performance for para-virtualized guests, but in general,
it's more beneficial to use the para-virtualization approach - since
most commonly the desired effect of a intercepted operation is more
complex than the single intercept, and often requires several
intercepts... As an example: To flush the page-table TLB, the programmer
will do:

        mov     %cr4, %rax
        mov     %rax, %rbx
        and     $~CR4_PGE, %rax    // Turn off PGE
        mov   %rax, %cr4
        mov     %rbx, %cr4

This will incur 3 intercepts (one for each "touch" of %cr4). In a
para-virtual OS, it can be reduced to a single function call that
perform the relevant TLB-flush code as a set. 

Likewise, if the guest is updating a range of page-table entries (say
the guest allocated a 4MB area of memory, this needs to be mapped from
guest-physical to virtual). This means (4MB/4KB pages) 1024 page-table
writes. In para-virtualization, you could batch these in a single cal to
the hypervisor, whilst the full virtualization is only seeing one
operation at a time, and doesn't get the "whole picture". 

--
Mats
        
> 
> Regards,
> 
> Joop Boonen.
> IP-Services.
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 
> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.