Memory locking limit and zero-copy migrations

Milan Zamazal
Thu, 18 Aug 2022 20:08:41 -0000

Fangge Jin <fjin at redhat.com> writes:

> On Thu, Aug 18, 2022 at 2:46 PM Milan Zamazal <mzamazal at
redhat.com> wrote:
>
>> Fangge Jin <fjin at redhat.com> writes:
>>
>> > I can share some test results with you:
>> > 1. If no memtune->hard_limit is set when start a vm, the
default memlock
>> > hard limit is 64MB
>> > 2. If memtune->hard_limit is set when start a vm, memlock hard
limit will
>> > be set to the value of memtune->hard_limit
>> > 3. If memtune->hard_limit is updated at run-time, memlock hard
limit
>> won't
>> > be changed accordingly
>> >
>> > And some additional knowledge:
>> > 1. memlock hard limit can be shown by ?prlimit -p
<pid-of-qemu> -l?
>> > 2. The default value of memlock hard limit can be changed by
setting
>> > LimitMEMLOCK in /usr/lib/systemd/system/virtqemud.service
>>
>> Ah, that explains it to me, thank you.  And since in the default case
>> the systemd limit is not reported in <memtune> of a running VM, I
assume
>> libvirt takes it as "not set" and sets the higher limit when
setting up
>> a zero-copy migration.  Good.
>>
> Not sure whether you already know this, but I had a hard time
> differentiating the two concepts:
> 1. memlock hard limit(shown by prlimit): the hard limit for locked host
> memory
> 2. memtune hard limit(memtune->hard_limit): the hard limit for in-use
host
> memory, this memory can be swapped out.

No, I didn't know it, thank you for pointing this out.  Indeed, 2. is
what both the libvirt and kernel documentation seem to say, although not
so clearly.

But when I add <memtune> with <hard_limit> to the domain XML and
then
start the VM, I can see the limit shown by `prlimit -l' is increased
accordingly.  This is good for my use case, but does it match what you
say about the two concepts?