[ovs-dev] [PATCH 3/3] util: munlockall() and retry when locked memory allocation fails

[Ilya Maximets]

On 3/26/21 9:18 PM, Ben Pfaff wrote:
> On Fri, Mar 26, 2021 at 07:52:18PM +0100, Ilya Maximets wrote:
>> On 3/26/21 7:30 PM, Ben Pfaff wrote:
>>> From: James Page <james.page at ubuntu.com>
>>>
>>> Normally when OVS runs on a server the effective system limit for
>>> locked memory is unlimited as the ovs-vswitchd runs as the root
>>> user in the root namespace of the server.
>>>
>>> When OVS is run in a non-priviledged container a system limit will
>>> apply and its possible that this limit will be reached during
>>> normal operation.
>>>
>>> If this occurs unlock all memory and re-attempt (re)allocation of
>>> memory rather than fail and abort.
>>>
>>> If this subsequent attempt also fails abort the process as before.
>>>
>>> Signed-off-by: James Page <james.page at ubuntu.com>
>>> [blp at ovn.org adapted to cover more cases]
>>> Signed-off-by: Ben Pfaff <blp at ovn.org>
>>> ---
>>
>> Hi, Ben and James.
>>
>> I'll repeat here what I said in a comment on github.
>>
>> DPDK uses memory locking for mempool pages and it relies on these
>> pages not being moved or unloaded, because it uses physical addresses
>> to configure hardware NICs.  Also, some DPDK drivers are using memory
>> locking to lock in memory pages that are used for driver-specific
>> device I/O.  Unlocking any of these pages in runtime will likely crash
>> the system by NMI if such a page will be moved or swapped without
>> notifying the device and driver.
>>
>> Blindly unlocking all the memory is very dangerous.
>>
>> I'd say it's much more safe to just run OVS without passing --mlockall.
>> Or we need to itroduce a special cmdline flag to allow dynamic unlocking
>> and also forbid DPDK initialization if this flag enabled.
>> And all this should be sufficiently documented.
> 
> I don't have a dog in this fight.  I'll leave it to you and James to
> figure out the preferred behavior.

Sure.  AFAIK, container management systems like kubernetes are tracking
memory consumption and doesn't schedule/create new containers if system
(kubelet daemon on the node) reports memory pressure.  So, it should not
be a big concern to run OVS without memory locking.

In its current form change is not acceptable as it will cause problems
for DPDK users (and, probably, afxdp, but I'm not sure about that).

> 
> Patches 1 and 2 may be of interest either way.
> 

Replied to these patches.

Best regards, Ilya Maximets.