Adjust memory initially allocated to service VMs

[marmarek]

Reported by joanna on 16 Mar 2011 00:44 UTC
I'm pretty sure they would need no more than 100MB or even less...

Migrated-From: https://wiki.qubes-os.org/ticket/114

[marmarek]

Comment by rafal on 25 Mar 2011 13:46 UTC
On both my test systems, netvm uses ca 130MB (200 including buffers/cache). Xorg, network manager, etc, etc, you have to feed all of them. I would vote for 200 MB limit (there is swap just in case), I have been running f13 netvm on 200MB for a few months. proxyvm can be thinner, 100MB looks fine.

[marmarek]

Comment by rafal on 25 Mar 2011 13:46 UTC
On both my test systems, netvm uses ca 130MB (200 including buffers/cache). Xorg, network manager, etc, etc, you have to feed all of them. I would vote for 200 MB limit (there is swap just in case), I have been running f13 netvm on 200MB for a few months. proxyvm can be thinner, 100MB looks fine.

[marmarek]

Comment by joanna on 25 Mar 2011 13:48 UTC
With those 200MB -- do you use some GUI there, e.g. nm-applet?

[marmarek]

Comment by joanna on 25 Mar 2011 13:48 UTC
With those 200MB -- do you use some GUI there, e.g. nm-applet?

[marmarek]

Comment by joanna on 30 Mar 2011 13:44 UTC
Now, when we have out magic suspend script for putting netvms into sleep without detaching the NICs from them, the fragmentation problem no longer troubles us, does it?

If so, I suggest that we include netvms (and proxyvms too) in our dynamic memory management. So, let's start every netvm/proxyvm with 200MB, and later use our dynamic mem management for further adjustments.

One catch: it might still happen that a netvm gets fragmented memory -- this is likely to occur if the user decided to restart the netvm sometime later after using the system for a while. This should not affect the default netvm because it is normally started very early (as the second netvm after the default firewallvm), so no fragmentation should occur at this stage. For now we can just say that in this case, user should reboot the system if decided to restart netvm during system life time.

[marmarek]

Comment by joanna on 30 Mar 2011 13:44 UTC
Now, when we have out magic suspend script for putting netvms into sleep without detaching the NICs from them, the fragmentation problem no longer troubles us, does it?

If so, I suggest that we include netvms (and proxyvms too) in our dynamic memory management. So, let's start every netvm/proxyvm with 200MB, and later use our dynamic mem management for further adjustments.

One catch: it might still happen that a netvm gets fragmented memory -- this is likely to occur if the user decided to restart the netvm sometime later after using the system for a while. This should not affect the default netvm because it is normally started very early (as the second netvm after the default firewallvm), so no fragmentation should occur at this stage. For now we can just say that in this case, user should reboot the system if decided to restart netvm during system life time.

[marmarek]

Comment by rafal on 30 Mar 2011 14:05 UTC
Yes, 130MB usage in netvm includes a running Xorg and nm-applet.

I still do not like the idea of dynamic memory management in service VMs.

Issue 1: What should we set the maxmem of netvm and proxyVM ? If we set it to the size of phys memory, like we do with appvms, we get ca 80MB of wasted RAM (for struct page array) for both netvm and proxyVM. The loss of 160MB will not be returned by the benefits of dynamic MM.
If we set it lower, then we will need nontrivial changes to qmemman to account for the fact that the maxmem is limited. Otherwise, if we set it to X and qmemman will try to assign X+delta to it, delta of RAM will be wasted.

Again, why to use dynamic MM for service VMs ? The memory usage should be quite constant - it is, according to half of year of experiments, so there is no need to increase the memory. We will not be able to dynamically go much lower than 200MB in netvm - as qmmeman assigns ca 1.3*used_ram for a VM, again we will land in the 200MB region.

I suggest to think it over for a while, and then decide finally.

[marmarek]

Comment by rafal on 30 Mar 2011 14:05 UTC
Yes, 130MB usage in netvm includes a running Xorg and nm-applet.

I still do not like the idea of dynamic memory management in service VMs.

Issue 1: What should we set the maxmem of netvm and proxyVM ? If we set it to the size of phys memory, like we do with appvms, we get ca 80MB of wasted RAM (for struct page array) for both netvm and proxyVM. The loss of 160MB will not be returned by the benefits of dynamic MM.
If we set it lower, then we will need nontrivial changes to qmemman to account for the fact that the maxmem is limited. Otherwise, if we set it to X and qmemman will try to assign X+delta to it, delta of RAM will be wasted.

Again, why to use dynamic MM for service VMs ? The memory usage should be quite constant - it is, according to half of year of experiments, so there is no need to increase the memory. We will not be able to dynamically go much lower than 200MB in netvm - as qmmeman assigns ca 1.3*used_ram for a VM, again we will land in the 200MB region.

I suggest to think it over for a while, and then decide finally.

[marmarek]

Modified by joanna on 30 Mar 2011 14:32 UTC

[marmarek]

Modified by joanna on 30 Mar 2011 14:32 UTC

[marmarek]

Comment by joanna on 5 Apr 2011 22:25 UTC
We really must reduce the default memory allocated to netvm and firewallvm. I suggest that we settle on fixed 200MB for each.

[marmarek]

Comment by joanna on 5 Apr 2011 22:25 UTC
We really must reduce the default memory allocated to netvm and firewallvm. I suggest that we settle on fixed 200MB for each.

[marmarek]

Modified by joanna on 6 Apr 2011 10:57 UTC

[marmarek]

Modified by joanna on 6 Apr 2011 10:57 UTC

[marmarek]

Modified by joanna on 6 Apr 2011 11:32 UTC

[marmarek]

Modified by joanna on 6 Apr 2011 11:32 UTC

[marmarek]

Modified by joanna on 6 Apr 2011 11:32 UTC

[marmarek]

Modified by joanna on 6 Apr 2011 11:32 UTC

[marmarek]

Comment by joanna on 6 Apr 2011 13:24 UTC
Done:

http://git.qubes-os.org/?p=joanna/core.git;a=commitdiff;h=d01489b48674834e8f44886b3127cd529e9399e2

[marmarek]

Comment by joanna on 6 Apr 2011 13:24 UTC
Done:

http://git.qubes-os.org/?p=joanna/core.git;a=commitdiff;h=d01489b48674834e8f44886b3127cd529e9399e2