[Bug 1920892] Re: locked memory allocation failure should fallback to unlocked memory

[James Page]

After some discussion upstream with OVS contributors there is alot of
other code (specifically in the DPDK codebase) which is materially
impacted with the fallback approach.

The consensus was that it would be better to simply disable mlock when
executing in a container - new PR raised to this effect:

https://github.com/openvswitch/ovs/pull/358

** Changed in: openvswitch (Ubuntu)
       Status: Triaged => In Progress

** Summary changed:

- locked memory allocation failure should fallback to unlocked memory
+ mlock should be disabled when running in containers

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to openvswitch in Ubuntu.
https://bugs.launchpad.net/bugs/1920892

Title:
  mlock should be disabled when running in containers

Status in openvswitch package in Ubuntu:
  In Progress

Bug description:
  When OVS is deployed inside of a LXD container the amount of locked
  memory is limited by the configured system limits for the container -
  until recently this was very small (64K) but was bumped to 16M and
  then 64M by recent changes into systemd.

  OVS will attempt to lock current and future memory allocations on
  startup - if this fails then subsequent memory allocations will not be
  locked but its not a fatal error - the daemons can still run, but
  there is a potential performance impact when memory contention occurs.

  @64K this happened reliably and the ovs-vswitchd daemon would run
  without locked memory.

  At 16M and 64M this is less clear cut - the initial mlockall call
  succeeds so the daemon runs with memory locking enabled for future
  malloc etc.. calls - if one fails then the daemon will abort.  On a
  modern server with many cores the amount of locked memory can quite
  easily exceed the now higher limits inside of a container.

  Outside of a container running as the root user the daemon has
  unlimited access to locked memory (to the physical memory limits of
  the server).

  Rather than completely disabling mlock when running in containers
  (which would be one approach to avoid this issue) it could be better
  to fallback to unlocked memory usage if the limit is hit.

  mmap and related calls would set EAGAIN when the limit is hit.

  Related bug 1906280.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1920892/+subscriptions