Messages in this thread | | | Subject | Re: [Xen-devel] [PATCH v3] xen/balloon: don't online new memory initially | From | Boris Ostrovsky <> | Date | Tue, 3 Oct 2017 17:33:25 -0400 |
| |
On 10/02/2017 05:37 PM, HW42 wrote: > Juergen Gross: >> When setting up the Xenstore watch for the memory target size the new >> watch will fire at once. Don't try to reach the configured target size >> by onlining new memory in this case, as the current memory size will >> be smaller in almost all cases due to e.g. BIOS reserved pages. >> >> Onlining new memory will lead to more problems e.g. undesired conflicts >> with NVMe devices meant to be operated as block devices. >> >> Instead remember the difference between target size and current size >> when the watch fires for the first time and apply it to any further >> size changes, too. >> >> In order to avoid races between balloon.c and xen-balloon.c init calls >> do the xen-balloon.c initialization from balloon.c. >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > This patch seems to introduce a regression. If I boot a HVM or PVH > domain with memory != maxmem then the kernel inside the domain reports > that it has maxmem available even though Xen reports only what is set as > memory. Sooner or later Xen logs "out of PoD memory!" and kills the > domain. If I revert the corresponding commit (96edd61d) then everything > works as expected. > > Tested this with Xen 4.9.0 and Linux 4.13.4. >
Yes, this indeed doesn't look like it's doing the right thing (although I haven't seen the "out of memory" error).
I wonder whether target_diff should be computed against xenstore's "static-max" and not "target" and the memory should be ballooned down immediately and not on a subsequent watch firing.
Unfortunately Juergen is out for a couple of weeks and I'd like to hear from him first since he is the one who wrote this patch.
-boris
[unhandled content-type:application/pgp-signature] | |