| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
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.
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home