[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] xl: neuter vcpu-set --ignore-host.
. 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |