Re: [Xen-devel] pre-reservation of memory for domain creation

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 12.01.10 16:04 >>>
>On 12/01/2010 14:47, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>> which would seem inconsistent with the current implementation in the
>> hypervisor: sh_set_allocation() as called from shadow_enable() wants
>> *at least* 4Mb - modified from 1Mb by c/s 20389. It is not clear (to me)
>> from the changeset description why this change was needed (and even
>> less why it was needed uniformly for 64- and 32-bits). If indeed it is
>> needed, the tools should be adjusted accordingly.
>
>ISTR trying the patch without the sh_set_allocation() chunk and failing to
>create many-VCPU HVM guests without it. Either the creation failed or Xen
>crashed (!) -- I can't remember which now, it may even have been both (with
>Xen crash during destruction of partially-created domain).

Hmm - given that we're talking about order-2 allocations here, it would
seem a mistake in the first place to use a fixed amount here if it really
depends on the number of vCPU-s. If that number isn't known at that
point (I think it isn't, since XEN_DOMCTL_createdomain doesn't take
it as input), the amount should be adjusted when setting that count
(i.e. from XEN_DOMCTL_max_vcpus).

Also - how did that fixed amount get determined?
shadow_min_acceptable_pages() says 128 pages per vCPU, but 4Mb
(1024 pages) is not matching this (given that it ought to be fine for
128 vCPU-s), just as the old value of 1Mb wasn't matching the
supposed need of 32 vCPU-s.

In any case - the larger the value here, the more likely VM creation
will fail due to fragmented memory (and fragmentation when using
ballooning here grows with the total amount of memory Dom0 owns).
Hence it's not even clear whether setting the pre-reservation value
to 8Mb would be good enough, or whether even 16Mb wouldn't
suffice in not too uncommon cases.

And btw., I think that papering over a Xen crash during
destruction of partially-created domain is rather bad a thing to do.

Jan


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