IMHO you should consider this a low prio, but very nice to have item.
Without it seems like calling for trouble later on.
Cases are:
a) Like John here unable to start guests they expected to be able to
b) (more critical) people that also changed vm.overcommit_memory to allow the initial alloc breaking hard later on.
In a perfect world I'd envision a slider like this:
* The recommended upper limit at (PhysMem-15%)+Swap
That way it would still be under the full control of the user, but this bug here would not grow into a common issue.
Until such code that adds something like an "upper recommended bound" is written you could just make things more clear with a comment at the slider maybe?
Therefore I'd be happy if you would consider this as a feature request.
@John - from your POV are you fine for now with the explanations or is there something else that was missed but is needed for you?
Good to know Blake, thanks.
IMHO you should consider this a low prio, but very nice to have item. memory to allow the initial alloc breaking hard later on.
Without it seems like calling for trouble later on.
Cases are:
a) Like John here unable to start guests they expected to be able to
b) (more critical) people that also changed vm.overcommit_
In a perfect world I'd envision a slider like this:
Overcommit ratio: ----|-- ------- ------- |
1.0 * 10
|------
* The recommended upper limit at (PhysMem-15%)+Swap
That way it would still be under the full control of the user, but this bug here would not grow into a common issue.
Until such code that adds something like an "upper recommended bound" is written you could just make things more clear with a comment at the slider maybe?
Therefore I'd be happy if you would consider this as a feature request.
@John - from your POV are you fine for now with the explanations or is there something else that was missed but is needed for you?