This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] Does dom0 see all physical processors? (RE:[Xen-ia64-dev

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: RE: [Xen-devel] Does dom0 see all physical processors? (RE:[Xen-ia64-devel] SAL INFO virtualization)
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 5 Apr 2006 15:32:34 +0100
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, okrieg@xxxxxxxxxx, Tristan Gingold <Tristan.Gingold@xxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 05 Apr 2006 07:32:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZXuYK0ne7FxazRSBOeDFMpHsl5NwAYvkYgAAF02OAAJFEm4AAByjZQ
Thread-topic: [Xen-devel] Does dom0 see all physical processors? (RE:[Xen-ia64-devel] SAL INFO virtualization)
> I believe ppc has "paravirtualized spinlocks" in their Linux 
> kernel, though even this won't necessarily help with a poorly 
> written SMP application.

We have an equivalent of this ("bad pre-emption mitigation"), along with
an alternative ("bad pre-emption avoidance"). Both have various pros and
cons, and can be shown to offer significant benefits in various
contrived benchmarks.

We have benchmark code that records when these bad pre-emptions happen,
and the workloads we've looked at we haven't been moved to check either
scheme in.

That's not to say that we won't have to at some point in the future, but
the limits to scalability are currently elsewhere. 

> > > So on a 16-processor system, every time dom0 needs to run 
> (e.g. to 
> > > handle backend I/O for any one of perhaps hundreds of domains), 
> > > *every* domain gets descheduled so that dom0 can be 
> (gang-)scheduled 
> > > on all 16 processors?
> > > 
> > > If true, this sounds like a _horrible_ performance hit, so I hope 
> > > I'm misunderstanding something...
> > 
> > This isn't an issue.
> > 
> > After booting you probably want dom0 to give up all but 1 
> vCPU anyway.
> Unless of course the PCPU's have data that change over time, 
> such as variable cycle rate (for power management) or 
> hot-plug memory...

Such events don't happen very often -- dom0 is still free to run
something on a given CPU whenever it wants to.


Xen-devel mailing list