[libvirt] [BUG] mlock support breakage

[Peter Krempa]

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 at redhat.com> 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 at redhat.com>
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170314/a0d974d4/attachment-0001.sig>