From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: unfair VCPU scheduling: slow HVM guest boot Date: Fri, 15 Aug 2008 13:50:07 +0200 Message-ID: <200808151350.07789.Christoph.Egger@amd.com> References: <200808151329.16470.Christoph.Egger@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap Cc: Keir Fraser , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Friday 15 August 2008 13:39:45 George Dunlap wrote: > The fact that there's different amounts of cpu time isn't evidence > that the scheduler is unfair. The vcpus may be blocked, or may be > coming up at different times. > > Is there a particular reason you want to run with more VCPUs than physical > cpus? Yes. You can have a virtual test/crash box for some development work, for example. > Given that cpu synchronization primitives like spinlocks and IPIs were > generally designed with the assumption that they're running on bare > metal and are not pre-empted, it's not surprising that when vcpus are > trying to work together but not able to run at the same time, there > will be performance problems. Yes, overcommitting always causes performance problems. The thing I am observing with xentop is that the last activated VCPU seems to be prefered over the others and the virtual BSP runs very rarely.= =20 That is what I mean by "unfair". Christoph > -George > > On Fri, Aug 15, 2008 at 12:29 PM, Christoph Egger > > wrote: > > Hi, > > > > Launch a HVM guest with twice as many VCPUs as physical CPUs are in the > > machine. You will notice the guest boots slow. > > > > With xentop you see, the first VCPU is rarely scheduled once the other > > VCPUs are up in the guest. > > If the boot process is just waiting for the first VCPU to finish > > something (e.g. handling an interrupt), then the whole boot process > > "freezes" until the first VCPU gets scheduled. > > > > Here is an xentop line showing how unfair the VCPUs are scheduled: > > > > VCPUs(sec): 0: 44s 1: 94s 2: 96s 3: = =20 > > 140s > > > > > > Christoph =2D-=20 AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Gesch=E4ftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplement=E4r: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Gesch=E4ftsf=FChrer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy