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

[Ben Pfaff]

On Wed, Apr 07, 2021 at 01:19:09PM +0200, Ilya Maximets wrote:
> 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).

Consider this dropped.