All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Egger <Christoph.Egger@amd.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>, xen-devel@lists.xensource.com
Subject: Re: unfair VCPU scheduling: slow HVM guest boot
Date: Fri, 15 Aug 2008 13:50:07 +0200	[thread overview]
Message-ID: <200808151350.07789.Christoph.Egger@amd.com> (raw)
In-Reply-To: <de76405a0808150439sd1cae61xa4b88f1c7e2bd727@mail.gmail.com>

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. 
That is what I mean by "unfair".

Christoph

>  -George
>
> On Fri, Aug 15, 2008 at 12:29 PM, Christoph Egger
>
> <Christoph.Egger@amd.com> 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:       
> > 140s
> >
> >
> > Christoph


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

      reply	other threads:[~2008-08-15 11:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-15 11:29 unfair VCPU scheduling: slow HVM guest boot Christoph Egger
2008-08-15 11:39 ` George Dunlap
2008-08-15 11:50   ` Christoph Egger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200808151350.07789.Christoph.Egger@amd.com \
    --to=christoph.egger@amd.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.