On 6/28/24 16:51, Eelco Chaudron wrote:
> 
> 
> 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]>
> 

Thanks, Eelco and Simon!  Applied.

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to