Re: CONFIG_NUMA and memory hotplug in i686 debian kernel
On Wed, Jan 28, 2015 at 8:37 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> 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?
Unfortunately I cannot name solid points from OSS world except
Proxmox, as most opensource orchestrators are still dealing with the
static memory config. In mine solution, we jumped to the ACPI hotplug
about a year a half ago, using QEMU as well, because ballooning has a
lot of disadvantages - limited scalability ratio (e.g. you cannot blow
an existing VM to be 20 times larger without power cycle because
reserved kernel memory will eat all available room for userspace
immediately at balloon driver initialization), limited compatibility
(guest OS needs an assisting mechanism, in same time ACPI hotplug is
widely available). For non-opensource examples I think I may point to
the ProfitBricks company, whose employee Vasilis Liaskovitis made the
first working implementation of hotplug mechanism for QEMU, myself
(FLOPS cloud platform) and Parallels solution.
>> >> 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.
Reply to: