Reading the Open vSwitch documentation for the --mlockall configuration option, used by default in ovs-ctl, suggests it should try to lock the memory and gracefully log a message if unsuccessful. If that indeed is the intent I think we should treat this as an Open vSwitch bug and seek a fix for it there.
That way we can postpone working out a generic way of giving unprivileged containers the memlock headroom they need until we have a clear set of use cases for it.
--mlockall Causes ovs-vswitchd to call the mlockall() function, to attempt
to lock all of its process memory into physical RAM, preventing
the kernel from paging any of its memory to disk. This helps to
avoid networking interruptions due to system memory pressure.
Some systems do not support mlockall() at all, and other systems
only allow privileged users, such as the superuser, to use it. ovs-vswitchd emits a log message if mlockall() is unavailable or unsuccessful.
Reading the Open vSwitch documentation for the --mlockall configuration option, used by default in ovs-ctl, suggests it should try to lock the memory and gracefully log a message if unsuccessful. If that indeed is the intent I think we should treat this as an Open vSwitch bug and seek a fix for it there.
That way we can postpone working out a generic way of giving unprivileged containers the memlock headroom they need until we have a clear set of use cases for it.
--mlockall
Causes ovs-vswitchd to call the mlockall() function, to attempt
to lock all of its process memory into physical RAM, preventing
the kernel from paging any of its memory to disk. This helps to
avoid networking interruptions due to system memory pressure.
Some systems do not support mlockall() at all, and other systems
ovs-vswitchd emits a log message if mlockall() is unavailable or
unsuccessful.
only allow privileged users, such as the superuser, to use it.