Re: Memory locking limit and zero-copy migrations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 19, 2022 at 08:01:58 +0200, Milan Zamazal wrote:
> Fangge Jin <fjin@xxxxxxxxxx> writes:
> 
> > On Fri, Aug 19, 2022 at 4:08 AM Milan Zamazal <mzamazal@xxxxxxxxxx> wrote:
> >
> >> > 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?
> >
> > memtune->hard_limit(hard limit of in-use memory) actually takes effect via
> > cgroup,
> > you can check the value by:
> > # virsh memtune uefi1
> > hard_limit     : 134217728
> > soft_limit     : unlimited
> > swap_hard_limit: unlimited
> > # cat
> > /sys/fs/cgroup/memory/machine.slice/machine-qemu\\x2d6\\x2duefi1.scope/libvirt/memory.limit_in_bytes
> >
> > 137438953472
> >
> > When vm starts with memtune->hard_limit set in domain XML, memlock
> > hard limit( hard_limit of locked memory, shown by 'prlimit -l')will be
> > set to the value of memtune->hard_limit. This's probably because
> > memlock hard limit must be less than memtune->hard_limit.
> 
> Well, increasing the memlock limit to keep it within memtune->hard_limit
> wouldn't make much sense, but thank you for confirming that setting
> memtune->hard_limit adjusts both the limits to the requested value.

Right, whenever libvirt needs to set a memory locking limit for zero
copy migration it uses memtune->hard_limit if it is set (RDMA migration
does the same), otherwise the configured memory amount for the domain is
used.

Anyway, unless you have a specific reason for setting the hard_limit,
it's usually better to leave it unset as the overall memory consumption
of a domain including the memory consumed by QEMU is hard to predict and
you would risk the domain to be killed unexpectedly by the kernel when
the limit is reached.

Jirka




[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux