Re: [Xen-devel] [PATCH 1/2] xl: neuter vcpu-set --ignore-host.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-09-26 at 21:52 -0400, Konrad Rzeszutek Wilk wrote:
> . snip..
> > > I do get your frustration - why would a normal user want to shoot 
> > > themselves
> > > in the foot with VCPU over-subscription? I have some faint clue - but I
> > > do to get a stream of requests from customers demanding it.
> > 
> > And not a single one has explained to you why they want it?
> > 
> > Or perhaps you could explain this faint clue of yours?
> 
> I believe it is mostly driven by VMWare making statements that this is a
> OK scenario (see ESXi CPU considerations in
> http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf)

The only reference to CPU (as opposed to memory) overcommit I can see in
there is:
        In most environments ESXi allows significant levels of CPU
        overcommitment (that is, running more vCPUs on a host than the
        total number of physical processor cores in that host) without
        impacting virtual machine performance.

I think this is pretty clearly referring to the case where the total of
all vCPUs across all guests exceeds the number of pCPUs. That kind over
overcommit is obviously fine, and not at all what I'm arguing against.

Nowhere in that doc did I get the impression that VMware were suggesting
that giving a single VM more vCPUs than the host has pCPUs was a useful
or sensible thing to do.

To be clear -- the patches you are proposing are removing the safety
catch preventing the latter (1 VM with vCPUs > pCPUs) not the former
(sum_all_VM(VCPUS_) > pCPUS). If xl is disallowing sum_all_VM(VCPUS_) >
pCPUS then there is a real bug. I don't believe this to be the case
though (if it is then we've been talking at cross purposes all along).

> > I'm not saying we can't make this change. I'm saying you haven't even
> > come close to giving a reasonable justification for it. I seem to
> > remember saying exactly the same thing last time we went around this
> > mulberry bush too.
> 
> I learned two new idioms today - mulberry bush and tosh today :-)

Sorry about that, was a bit grumpy.
 
> > >  And if they pay to
> > > shoot themselves in the foot - well, here is a cocked gun and let me 
> > > point the
> > > gun at your foot and you can pull the trigger.
> > 
> > They can use the override.
> 
> Yes they can. I am was hoping we would allow a non override mode for
> those who really don't want any of these overrides. George suggested the
> "seatbelt" option and that looks to be a good compromise for me.

AIUI the "seatbelt" to which George was referring is the current
behaviour (i.e. the override). He said:
        So given what all of us think, keeping the "seatbelt" is
        probably the best compromise.

i.e. to him the seatbelt is the status quo.

So what do you mean by seatbelt?

Or do you just mean to add the restriction + override to xl create too?
That would be good.

> > > Lastly, now that the PV ticketlocks are in and they work for both PV and
> > > HVM I am curious how many people are going to start using it.
> > 
> > Why would they? What possible benefit is there to doing this whether or
> > not PV ticketlocks are available?
> 
> Because now one can run Linux guests without incuring huge latency waits
> due to spinlock contention. This makes it possible to actually compile a
> Linux kernel with massively overcommited scenarios.

But *why*, for what possible reason would a user want do that? That is
the key question which has never been answered and that's why I keep
nacking this patch.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel