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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

. 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)
> 
> 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 :-)
> 
> >  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.

> 
> > 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.

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