[Xen-cim] Re: Removing pcpus from the scheduling pool

[Emmanuel Ackaouy <ackaouy@xxxxxxxxx>]

I think what you want to do here is restrict every domain to run only on
a subset of the available physical CPUs except for the management
domain(s) which would be either unrestricted or restricted to their
own dedicated set of physical CPUs.

For example, on a 4-way host, you could set dom0's cpumask to "0"
(run only on CPU 0) while every other domain's cpumask would be
set to "1-3" (run only on CPUs 1, 2, or 3, but NOT 0).

You can do this today using the vcpu-pin / cpumask interface.

Eventually, I would like to add support for cpusets such that the
host system can be carved into zones. VMs could be assigned
to run in specific zones. This will be more straightforward but it
is not work that I have even started on yet.

Emmanuel.

On Dec 19, 2006, at 16:01, Subrahmanian, Raj wrote:

> Emmanuel,
>
> The Xen-CIM team has a requirement that we should be able to remove
> PCPUs from the scheduling pool. I quote..
> > * Support for ResourcePoolConfigurationService on some pool types,
> > e.g. ProcessorPool.This functionality will support for example
> > removing PCPUs from the pool and dedicate to management domain, thus
> > restricting set of PCPUs available for consumption by VMs.  Does xen
> support
> > this?  Can we mask PCPUs such that they are not available to VMs?
> End quote.
>
> What needs to be done to add this functionality to the current
> scheduler?
>
> Alternately, since you mentioned that vcpu-pinning is not-soft, is it
> possible that if we ran a dummy VM that was pinned to the pcpus, we
> could do something so we would not be preempted (that would keep those
> pcpus from being released into the general scheduling pool)? Is that
> even possible? Or would it be more complicated than merely patching the
> scheduler and providing a path to doing it via xend?
> > VCPU affinity should not be soft. By the time the set
> > affinity hypercall returns, the VCPU in question should be
> > running on a physical CPU set in its affinity mask.
> Thanks
> Raj

_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim