[pve-devel] [PATCH] memory hotplug patch v6
Daniel Hunsaker
danhunsaker at gmail.com
Tue Jan 20 20:40:30 CET 2015
It's a bit more work internally, but changing the RAM size seems like a
task that could be handled without thinking about the add/remove process.
Present the user with a button/dialog to resize RAM, then hotplug and/or
unplug to arrive at the target. If they provide a larger value than what's
currently plugged in, hotplug the appropriate size and number of DIMMs. If
it's smaller, and the size difference matches one of the currently inserted
DIMMs, unplug it; otherwise find a DIMM that's larger than the size
difference, plug a new module that will provide the difference between that
larger DIMM and the reduced target, then unplug the larger one. If all the
existing DIMMs are smaller than the size difference, you can follow a
similar logic path by treating groups of two or more DIMMs as the unplug
target mentioned above - if a given DIMM group matches the size difference,
unplug that group; if not, find the smallest group of DIMMs you can unplug
to reach the target, plug a new DIMM that will provide the amount of RAM
you don't want to remove, and then unplug the group.
Some scenarios to illustrate what I'm suggesting, since even I understand
what I mean better that way than what I just said above. Each scenario
builds from the previous one; the first starts with a current RAM size of
512M, using a DIMM configuration of 1 x 512M modules.
Scenario 1:
Target RAM - 1024M
Action - plug 1 x 512M
Result - 1024M (2 x 512M)
Scenario 2:
Target RAM - 512M
Action - unplug 1 x 512M
Result - 512M (1 x 512M)
Scenario 3:
Target RAM - 256M
Action - plug 1 x 256M; unplug 1 x 512M
Result - 256M (1 x 256M)
After some more mucking about, adding memory at 256M increments, the user
arrives at a configuration of 1024M (4 x 256M) for the following scenarios.
Scenario 4:
Target RAM - 512M
Action - unplug 2 x 256M
Result - 512M (2 x 256M)
Scenario 5:
Target RAM - 128M
Action - plug 1 x 128M; unplug 2x256M
Result - 128M (1 x 128M)
A bit contrived, but illustrates the process I'm proposing. I strongly
suspect that's what the other virtualization platforms are doing internally
as well. It certainly simplifies the process for users who don't feel
comfortable managing NUMA and similar settings directly, though it does
increase the complexity of our code, and I'm certain I've simplified things
here immensely.
Just another option to consider. Either way, I like the idea of a simple
process for admins in a hurry, and an advanced interface for those who are
comfortable with NUMA and want complete control over their memory map.
On Tue, Jan 20, 2015, 10:21 Gilberto Nunes <gilberto.nunes32 at gmail.com>
wrote:
> BTW, how can I test this Alexandre??
>
> 2015-01-20 15:19 GMT-02:00 Gilberto Nunes <gilberto.nunes32 at gmail.com>:
>
> +1
>>
>> I am the one that want to see this feature in production environment....
>> It will be a plus...
>>
>>
>>
>> 2015-01-20 15:13 GMT-02:00 Alexandre DERUMIER <aderumier at odiso.com>:
>>
>> >>I wonder if memory unplug is a good idea? I assume that will be the
>>> fastest way
>>> >>to crash most OS?
>>> I personnaly need this feature. (I have customers which want to
>>> add/remove memory, because we bill on that).
>>>
>>> For linux, it should work without any problem, if you have memory use
>>> for buffer.
>>> (Of course if your process need memory, you'll get OOM for sure)
>>>
>>>
>>>
>>> ----- Mail original -----
>>> De: "dietmar" <dietmar at proxmox.com>
>>> À: "aderumier" <aderumier at odiso.com>
>>> Cc: "pve-devel" <pve-devel at pve.proxmox.com>
>>> Envoyé: Mardi 20 Janvier 2015 18:09:13
>>> Objet: Re: [pve-devel] [PATCH] memory hotplug patch v6
>>>
>>> > what we can do
>>> > -------------
>>> >
>>> > I think we can add a button "add-> memory hotplug", with a field with
>>> memory
>>> > value wanted.
>>> > We display the total memory in current hardware grid memory field.
>>> (memory +
>>> > total of dimms memories).
>>> >
>>> > For unplug, create a button "delete->memory unplug",
>>> > and in the form, display a combobox with list of current memory modules
>>>
>>> I wonder if memory unplug is a good idea? I assume that will be the
>>> fastest way
>>> to crash most OS?
>>> _______________________________________________
>>> pve-devel mailing list
>>> pve-devel at pve.proxmox.com
>>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>>
>>
>>
>>
>> --
>> --
>> "A única forma de chegar ao impossível, é acreditar que é possível."
>> Lewis Carroll - Alice no País das Maravilhas
>>
>> "“*The only way* to achieve *the impossible is to believe* it is
>> *possible*.”
>> Lewis Carroll - Alice in Wonderland
>>
>> Gilberto Ferreira
>> (47) 9676-7530
>>
>>
>
>
> --
> --
> "A única forma de chegar ao impossível, é acreditar que é possível."
> Lewis Carroll - Alice no País das Maravilhas
>
> "“*The only way* to achieve *the impossible is to believe* it is
> *possible*.”
> Lewis Carroll - Alice in Wonderland
>
> Gilberto Ferreira
> (47) 9676-7530
>
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20150120/2710df86/attachment.htm>
More information about the pve-devel
mailing list