On 14 Jun 2024, at 14:22, Ilya Maximets wrote:
> The main purpose of locking the memory is to ensure that OVS can keep
> doing what it did before in case of increased memory pressure, e.g.,
> during VM ingest / migration. Fulfilling this requirement can be
> achieved without locking all the allocated memory, but only the pages
> already accessed in the past (faulted in). Processing of the new
> traffic involves new memory allocations. Latency on these operations
> can't be guaranteed by the locking. The main difference would be
> the pre-faulting of the stack memory. However, in order to revalidate
> or process upcalls on the same traffic, the same amount of stack is
> likely needed, so all the necessary memory will already be faulted in.
>
> Switch 'mlockall' to MCL_ONFAULT to avoid consuming unnecessarily
> large amounts of RAM on systems with high core counts. For example,
> in a densely populated OVN cluster this saves about 650 MB of RAM per
> node on a system with 64 cores. This equates to 320 GB of allocated
> but unused RAM in a 500 node cluster.
>
> This also makes OVS better suited by default for small systems with
> limited amount of memory.
>
> The MCL_ONFAULT flag was introduced in Linux kernel 4.4 and wasn't
> available at the time of '--mlockall' introduction, but we can use it
> now. Falling back to an old way of locking in case we're running on
> an older kernel just in case.
>
> Only locking the faulted in pages also makes locking compatible with
> vhost post-copy live migration by default, because we'll no longer
> pre-fault all the guest's memory. Post-copy relies on userfaultfd
> to work on shared huge pages, which is only available in 4.11+ kernels.
> So, technically, it should not be possible for MCL_ONFAULT to fail and
> the call without it to succeed. But keeping the check just in case
> for now.
>
> Signed-off-by: Ilya Maximets <[email protected]>
This change looks good. I did some performance testing and I noticed not
negative impacts.
Acked-by: Eelco Chaudron <[email protected]>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
