Fangge Jin <fjin@xxxxxxxxxx> writes: > On Thu, Aug 18, 2022 at 2:46 PM Milan Zamazal <mzamazal@xxxxxxxxxx> wrote: > >> Fangge Jin <fjin@xxxxxxxxxx> 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?
