<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Scenario 1:<br>
Target RAM - 1024M<br>
Action - plug 1 x 512M<br>
Result - 1024M (2 x 512M)</p>
<p dir="ltr">Scenario 2:<br>
Target RAM - 512M<br>
Action - unplug 1 x 512M<br>
Result - 512M (1 x 512M)</p>
<p dir="ltr">Scenario 3:<br>
Target RAM - 256M<br>
Action - plug 1 x 256M; unplug 1 x 512M<br>
Result - 256M (1 x 256M)</p>
<p dir="ltr">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.</p>
<p dir="ltr">Scenario 4:<br>
Target RAM - 512M<br>
Action - unplug 2 x 256M<br>
Result - 512M (2 x 256M)</p>
<p dir="ltr">Scenario 5:<br>
Target RAM - 128M<br>
Action - plug 1 x 128M; unplug 2x256M<br>
Result - 128M (1 x 128M)</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<br><div class="gmail_quote">On Tue, Jan 20, 2015, 10:21 Gilberto Nunes <<a href="mailto:gilberto.nunes32@gmail.com">gilberto.nunes32@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">BTW, how can I test this Alexandre??<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-20 15:19 GMT-02:00 Gilberto Nunes <span dir="ltr"><<a href="mailto:gilberto.nunes32@gmail.com" target="_blank">gilberto.nunes32@gmail.com</a>></span>:</div></div><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>+1<br><br></div>I am the one that want to see this feature in production environment....<br></div>It will be a plus...<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-20 15:13 GMT-02:00 Alexandre DERUMIER <span dir="ltr"><<a href="mailto:aderumier@odiso.com" target="_blank">aderumier@odiso.com</a>></span>:<div><div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>>>I wonder if memory unplug is a good idea? I assume that will be the fastest way<br>
>>to crash most OS?<br>
</span>I personnaly need this feature. (I have customers which want to add/remove memory, because we bill on that).<br>
<br>
For linux, it should work without any problem, if you have memory use for buffer.<br>
(Of course if your process need memory, you'll get OOM for sure)<br>
<span><br>
<br>
<br>
----- Mail original -----<br>
De: "dietmar" <<a href="mailto:dietmar@proxmox.com" target="_blank">dietmar@proxmox.com</a>><br>
À: "aderumier" <<a href="mailto:aderumier@odiso.com" target="_blank">aderumier@odiso.com</a>><br>
Cc: "pve-devel" <<a href="mailto:pve-devel@pve.proxmox.com" target="_blank">pve-devel@pve.proxmox.com</a>><br>
</span>Envoyé: Mardi 20 Janvier 2015 18:09:13<br>
<span>Objet: Re: [pve-devel] [PATCH] memory hotplug patch v6<br>
<br>
</span><div><div>> what we can do<br>
> -------------<br>
><br>
> I think we can add a button "add-> memory hotplug", with a field with memory<br>
> value wanted.<br>
> We display the total memory in current hardware grid memory field. (memory +<br>
> total of dimms memories).<br>
><br>
> For unplug, create a button "delete->memory unplug",<br>
> and in the form, display a combobox with list of current memory modules<br>
<br>
I wonder if memory unplug is a good idea? I assume that will be the fastest way<br>
to crash most OS?<br>
_______________________________________________<br>
pve-devel mailing list<br>
<a href="mailto:pve-devel@pve.proxmox.com" target="_blank">pve-devel@pve.proxmox.com</a><br>
<a href="http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel" target="_blank">http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel</a><br>
</div></div></blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>--</div><div>"A única forma de chegar ao impossível, é acreditar que é possível."<br>Lewis Carroll - Alice no País das Maravilhas<br><br>"<span>“<i>The only way</i> to achieve <i>the impossible is to believe</i> it is <i>possible</i>.”</span><br></div><div>Lewis Carroll - Alice in Wonderland<br></div><div><br></div><div>Gilberto Ferreira<br><a href="tel:%2847%29%209676-7530" value="+554796767530" target="_blank">(47) 9676-7530</a><br></div><br></div></div></div></div></div></div></div></div>
</font></span></div>
</blockquote></div></div><div class="gmail_extra"><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>--</div><div>"A única forma de chegar ao impossível, é acreditar que é possível."<br>Lewis Carroll - Alice no País das Maravilhas<br><br>"<span>“<i>The only way</i> to achieve <i>the impossible is to believe</i> it is <i>possible</i>.”</span><br></div><div>Lewis Carroll - Alice in Wonderland<br></div><div><br></div><div>Gilberto Ferreira<br>(47) 9676-7530<br></div><br></div></div></div></div></div></div></div></div>
</div>
______________________________<u></u>_________________<br>
pve-devel mailing list<br>
<a href="mailto:pve-devel@pve.proxmox.com" target="_blank">pve-devel@pve.proxmox.com</a><br>
<a href="http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel" target="_blank">http://pve.proxmox.com/cgi-<u></u>bin/mailman/listinfo/pve-devel</a><br>
</blockquote></div>