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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-09-26 at 11:28 -0400, Konrad Rzeszutek Wilk wrote:
> > >  - The user can already boot a massively overcommitted guest by
> > >    having a large 'vcpus=' value in the guest config and we allow
> > >    that.
> > 
> > IMHO this is an xl bug, I'd be happy to see a patch to fix this and
> > require and override here too.
> 
> I actually think that doing vCPU overcommit is an OK process. If you go
> down the path of 'don't do this b/c it can cause performance degredation'
> you might end up with tons of things that we should be turning off:
>  - don't use file but use phy for block.
>  - if you have 40GB SR-IOV, use that instead of vif.
>  - booting PV? You should be booting it in HVM mode on latest machines.
>  - etc.

Those are all legitimate choices for a user to make. 

Overcommitting VCPUs is not.

Choosing to overcommit VCPUs is useful in exactly one scenario --
testing how bad CPU overcommit makes things. That is an expert use case
and a legitimate reason to use an override.

I've asked *repeatedly* now for an actual use case where a user would
want to overcommit. IMHO it is always an accident/user error to do this.
If you have an actual use case then please share it, the presence of
such a thing would go a long way to changing my opinion.

> They are all in some cases subjective and the user can have a legitimate
> reason to do this instead of using one we think is better.
> 
> I want the user to be able to make that choice without constraining
> them. This is open source after all - we lift the barriers, not put them
> in.

I'm not even going to dignify this kind of vapid tosh with a response.

> I think adding the WARNING is a good idea (which is how it does it
> right now). But this is the similar as running a guest on a NUMA machine
> without putting it in proper NUMA containers

It's not at all the same as that. In that case we can apply sensible
defaults etc, as Dario has been doing.

>  - we should WARN, not just
> outright stop the guest.
> > 
> > This change need far better rationalisation than "because xend did it"
> > and "because we can". IMHO.
> 
> From my non-technical view (and I am not sure if I had made this clear)
> there is a lot of users that use 'xend' and want to switch to 'xl'. As such
> to make this backwards compatible, even bugs have be considered. Perhaps
> another way to do this is to have a global flag - 'xend_compatible' where
> even things that are bugs are expected to work certain ways.

If xend were still being maintained this is exactly the sort of
improvement I would advocate making to it. Yes that would mean xend
behaved differently for xend users in the next release. I would call it
an improvement or a bugfix not an incompatibility. You seem to think
xend has or had some sort of CLI compatibility guarantee, which it
did/does not, when it was developed it was changed regularly (for,
mostly, good reasons).

There is no reason to reimplement xend bugs in xl. Nor is "xl must be
compatible with xend" a reason to avoid making progress which we would
have been making with xend anyway if it were still being developed.

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

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

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

> Sorry about the long twisted answer - I hope this will get the discussion a 
> bit
> more going forward so we can decide what we want to do for Xen 4.4.



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