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

Re: [Xen-devel] [PATCH 0/8] Various VPMU patches


  • To: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • From: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>
  • Date: Wed, 10 Apr 2013 10:57:42 +0200
  • Cc: jacob.shin@xxxxxxx, haitao.shan@xxxxxxxxx, jun.nakajima@xxxxxxxxx, suravee.suthikulpanit@xxxxxxx, xen-devel@xxxxxxxxxxxxx
  • Delivery-date: Wed, 10 Apr 2013 08:57:59 +0000
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:From:To:Cc:Subject:Date:Message-ID: User-Agent:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding:Content-Type; b=SwPzsLndgdwfec0XhaO9bJ/0ku71qivZuysij8p9Ya2/rQCzBVC/mzb1 bLBt0YIP2zCdlBdotqFStoRKgrN3qFeXtW9qS8Kqy0zCdgDb7gI3WynB2 25PFVQoHFC92moGpcUHbyOTZAAUU5v52AWQ2/EB/RZrvy/pcATCRXs4C5 mZqB3BcudGnL7z0u46yBaI813PGw6DYrYKfOJxCjjzB3z/sbmmo31yihh lavtcp/sI4ATwgo8Ymu7wcFUEzig2;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

Am Dienstag 09 April 2013, 13:26:11 schrieb Boris Ostrovsky:
> Here is a set of VPMU changes that I thought might be useful.
> 
> The first two patches are to avoid VMEXITs on certain MSR accesses. This
> is already part of VMX so I added similar SVM code
> 
> The third patch should address the problem that Suravee mentioned on the
> list a few weeks ago 
> (http://lists.xen.org/archives/html/xen-devel/2013-03/msg00087.html). 
> It's a slightly different solution then what he suggested.
> 
> 4th patch stops counters on AMD when VCPU is de-scheduled
> 
> 5th is trivial Haswell support (new model number)
> 
> 6th patch is trying to factor out common code from VMX and SVM.
> 
> 7th is lazy VPMU save/restore. It is optimized for the case when CPUs are
> not over-subscribed and VCPU stays on the same processor most of the time.
> It is more beneficial on Intel processors because HW will keep track of
> guest/host global control register in VMCS and tehrefore we don't need to
> explicitly stop the counters. On AMD we do need to do this and so while
> there is improvement, it is not as pronounced.
> 
> Here are some numbers that I managed to collect while running guests with
> oprofile. This is number of executed instructions in vpmu_save/vpmu_load.
> 
>               Eager VPMU                 Lazy VPMU
>            Save      Restore       Save      Restore
> Intel      181       225            46         50
> AMD        132       104            80        102
> 
> When processors are oversubscribed, lazy restore may take about 2.5 times
> as many instructions as in the dedicated case if new VCPU jumps onto the 
> processor (which doesn't happen on every context switch). 
> 
> 
> -boris

Good work!

Reviewed-by: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>

For Intel:
Tested-by: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>

Dietmar.

> 
> 
> Boris Ostrovsky (8):
>   x86/AMD: Allow more fine-grained control of VMCB MSR Permission Map
>   x86/AMD: Do not intercept access to performance counters MSRs
>   x86/AMD: Read VPMU MSRs from context when it is not loaded into HW
>   x86/AMD: Stop counters on VPMU save
>   x86/VPMU: Add Haswell support
>   x86/VPMU: Factor out VPMU common code
>   x86/VPMU: Save/restore VPMU only when necessary
>   x86/AMD: Clean up context_update() in AMD VPMU code
> 
>  xen/arch/x86/domain.c                    |  14 ++-
>  xen/arch/x86/hvm/svm/svm.c               |  19 ++--
>  xen/arch/x86/hvm/svm/vpmu.c              | 188 
> +++++++++++++++++++++++--------
>  xen/arch/x86/hvm/vmx/vmx.c               |   2 -
>  xen/arch/x86/hvm/vmx/vpmu_core2.c        |  48 ++++----
>  xen/arch/x86/hvm/vpmu.c                  | 114 +++++++++++++++++--
>  xen/include/asm-x86/hvm/svm/vmcb.h       |   8 +-
>  xen/include/asm-x86/hvm/vmx/vpmu_core2.h |   1 -
>  xen/include/asm-x86/hvm/vpmu.h           |   6 +-
>  9 files changed, 296 insertions(+), 104 deletions(-)
> 
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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