On Fri, Jun 14, 2024 at 02:22:47PM +0200, 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]>
Acked-by: Simon Horman <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
