On Mon, Mar 13, 2017 at 18:16:49 +0000, Daniel Berrange wrote:
> On Mon, Mar 13, 2017 at 02:08:30PM -0400, Luiz Capitulino wrote:
> > On Mon, 13 Mar 2017 13:53:33 -0400
> > Luiz Capitulino <lcapitulino@xxxxxxxxxx> wrote:
> >
> > > OK, you're right. I personally don't like we're putting a random cap
> > > on QEMU memory allocations, but if it's large enough it shouldn't be
> > > a problem (I hope).
> >
> > The I hope part meaning, if we do find legitimate reasons for QEMU's
> > address space to go beyond $LARGE_NUMBER, it will be means of guests
> > randomly crashing when using <locked/>.
>
> NB if we did enforce $RAM + $LARGE_NUMBER, then I'd suggest we did
> set a default hard_limit universally once more, not only set a mlock
We were already attempting to do this and we reverted it since there's
no deterministic $LARGE_NUMBER which would work for all cases.
I can imagine this working if $LARGE_NUMBER is infinity or host
memory+swap size.
commit 16bcb3b61675a88bff00317336b9610080c31000
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date: Fri Aug 9 14:46:54 2013 +0200
qemu: Drop qemuDomainMemoryLimit
This function is to guess the correct limit for maximal memory
usage by qemu for given domain. This can never be guessed
correctly, not to mention all the pains and sleepless nights this
code has caused. Once somebody discovers algorithm to solve the
Halting Problem, we can compute the limit algorithmically. But
till then, this code should never see the light of the release
again.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
