On Wed, 2015-01-28 at 21:26 +0400, Andrey Korolyov wrote: > On Wed, Jan 28, 2015 at 8:17 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > > On Wed, 2015-01-28 at 16:26 +0400, Andrey Korolyov wrote: > >> Hello Ben, > >> > >> though it may be better place to ask you same question in one of many > >> debian mls, I hope that the raised matter may be important enough for > >> a default kernel config change. > > > > In any case, this belongs on the mailing list > > (debian-kernel@lists.debian.org). > > > >> Not long ago, QEMU project implemented native ACPI-based memory > >> hotplug which is generally more convenient to use than a lot of > >> different ballooning mechanisms and all VM orchestration solutions > >> will neither offer both methods of RAM size management or migrate to > >> ACPI-based hotplug, dropping ballooning completely. > > > > Can you be more specific? Which systems have changed or are going to > > change? > > Technically speaking, there is a potential interest only for i686-PAE > configuration, I hardly imagine necessity to run other i386 flavors > with simultaneous need to resize memory on-the-fly in a virtualized > environment. My question was which VM orchestration systems are changing? > >> The problem is > >> that the Debian i686 kernel, of which you are taking a part of > >> responsibility, does not allow to use memory hotplug in guest due to > >> disabled CONFIG_NUMA (though technically it would be possible to do > >> so, after considering some changes in kernel itself). Are there any > >> serious implications to maintain this option as it or it can be turned > >> on in next or -backport series? > > > > CONFIG_NUMA is not currently enabled as there is little reason for it on > > a physical 32-bit system. In what way does memory hotplug depend on > > this? Does it not work properly without CONFIG_DISCONTIGMEM_MANUAL or > > CONFIG_SPARSEMEM_MANUAL? > > Sorry, my bad - CONFIG_SPARSEMEM_MANUAL is necessary, and it depends > on CONFIG_NUMA. It could be selected by default as soon as its > requirements will be fulfilled, e.g. there are absolutely no > performance cost so far by my knowledge. OK, that makes sense. This could probably still be changed for jessie if it's really necessary. As it requires an ABI change this will not be changed for wheezy. Ben. > Please CC me in replies as I am not a direct subscriber of debian-kernel. > > -- Ben Hutchings Teamwork is essential - it allows you to blame someone else.
Attachment:
signature.asc
Description: This is a digitally signed message part