On Tue, Jun 23, 2015 at 3:32 PM, Piotr Rybicki <piotr.rybi...@innervision.pl> wrote: >> Thanks Piotr, the lack of the host-side memory shrinkage after balloon >> deflation is interesting anyway, hopefully you may share guest` dmesg >> bits from compiled-in balloon to check visible signs of the issue > > > It is really hard to see dmesg output via vnc console, when kernel is > sending so many messages looped :( > >> (balloon should be initialized *before* DIMMs are being onlined, so >> the behavior of the balloon itself it not clear at least for me). > > > Why balloon should be initialized before DIMMs onlined?
For compiled-in balloon, its initialization should be done earlier than the udev, because the kernel is not switched to init execution yet. > > DIMMS are onlined as soon as udev starts (i have udev rule to online mem, > cpu), so system has to start init process. I don't see any option to online > DIMMs before booting reaches init process. > > With balloon compiled-in, it starts to shrink memmory (for example to shrink > 8GB, when 1GB 'base' mem is defined, and 10GB in DIMMs), when there is only > 1GB 'base' memory. This leads to problem > > With balloon loaded as a module, shrinking starts after init has begun > (because system has to at least mount filesystem where balloon module is > placed to load) > > Well, i can't proove this with dmesg, but with balloon as module - system is > booting and working as expected. With balloon compiled-in - system does not > boot saying there is no free mem for balloon to shrink it. Thanks, this is an unexpected behavior, because you are starting with small amount of total memory exposed to a balloon at the beginning and there should be no issues except if the inflation races with plugging in new DIMMs (just a wild guess), dmesg output will be helpful there as I pointed earlier. > > Best regards > Piotr Rybicki >
